< phantomcircuit>
is anybody using the rest interface?
< phantomcircuit>
it seems like a non-trivial amount of code to expose as an unauthenticated endpoint
< phantomcircuit>
jonasschnelli, ^
< jonasschnelli>
phantomcircuit: mind the -rest arg
< phantomcircuit>
ah it has to be explicitly enabled? how did i miss that...
< jonasschnelli>
Yes...
< jonasschnelli>
But agree.
< jonasschnelli>
Rest could be useful for decoupling the wallet
< gmaxwell>
phantomcircuit: yes, it's an attack vector, thats why it's been off by default... also why we kept json out of it. (thank god..)
< gmaxwell>
phantomcircuit: I've fuzz tested it some but still don't feel all that confident about it's security.
< jonasschnelli>
gmaxwell: json is in there... :)
< gmaxwell>
jonasschnelli: we kept json input out of it.
< jonasschnelli>
Ah.. not as decoding. right.
< jonasschnelli>
There is encoding.
< gmaxwell>
which is why that bug in univalue wasn't a unauthenticated remotely exploitable bug.
< jonasschnelli>
Yes... long term im worries about the amount of APIs in bitcoin-core: RPC/REST/ZMQ/notify-exe/p2p....
< jonasschnelli>
*I'm worried
< phantomcircuit>
jonasschnelli, i strongly believe the zmq interface is unsafe
< gmaxwell>
the ZMQ libraries themselves aren't secure in my past expirence.
< jonasschnelli>
And I have plans to introduce another... :)
< jonasschnelli>
well... not anthoer.
< gmaxwell>
but hopefully no one is exposing ZMQ in untrusted ways.
< phantomcircuit>
... what port does it listen on by default?
< jonasschnelli>
Writing a BIP about extending the p2p protocol for private/encrypted messages.
< jonasschnelli>
Things like "estimatefee", etc.
< jonasschnelli>
To couple a SPV wallet over p2p
< phantomcircuit>
jonasschnelli, keep in mind that BGP attacks are very real when proposing such a protocol
< jonasschnelli>
phantomcircuit: I'm not familiar with BGP attacks,.. can you explain that a little bit?
< jonasschnelli>
The idea I have is a "auth" p2p command,... that authenticates a nodes against a pubkey (nonce signing or similar), after the auth, do a ECDH and encrypt further communication (maybe only the additional/private commands).
< phantomcircuit>
jonasschnelli, essentially an attacker can claim to route a third parties traffic and perform a perfect mitm attack
< jonasschnelli>
I think with preshared keys and ECDH we can avoid a mitm.
< jonasschnelli>
The ECDH would only happen if the auth against a preshared pubkey on the node was successfull.
< phantomcircuit>
unfortunately i think basically what we would want is tls... except tls is a nightmare
< jonasschnelli>
I guess this would allow to expose things like "estimatefee" to a single node (SPV) without opening a new DOS vector.
< jonasschnelli>
No tls please!
< jonasschnelli>
It's already possible with tunneling.
< jonasschnelli>
But user experience is bad
< phantomcircuit>
jonasschnelli, i dont see a good reason to do that though
< phantomcircuit>
"please show me the top x MB of your mempool" is more generic and allows the client to come to it's own conclusions
< jonasschnelli>
main advantages of encrypted and extendable p2p com: a) SPV privacy improvement against a trusted full node (mitm impossible) b) additional wallet services
< jonasschnelli>
I guess: "please show me the top x MB of your mempool" is not pratical long term for SPV.
< jonasschnelli>
And with encrypted and extendable p2p commands, we could also decouple the node control (UI). The UI could talk with the node over p2p 8333.
< jonasschnelli>
(Which is somehow very difficult over RPC)
< phantomcircuit>
jonasschnelli, the ui and wallet should both just be spv clients which trust the full node "server" completely
< jonasschnelli>
phantomcircuit: but could the UI (if detached from the node) get peer informations, mempool insights, etc?
< jonasschnelli>
phantomcircuit: how could the wallet get fee rates?
< phantomcircuit>
jonasschnelli, peer info no, mempool... yes if bandwidth between the two doesn't matter
< phantomcircuit>
(and it doesn't because localhost)
< phantomcircuit>
(or lan)
< jonasschnelli>
What if you wan't to have a secure SPV wallet on your cellphone?
< phantomcircuit>
jonasschnelli, get the full data for the last n blocks and the top n mb of mempool and build the fee estimates db itself
< jonasschnelli>
Not sure if you wan't to do fee ests. on a smartphone if you also run a full node at home.
< jonasschnelli>
somehow I think the model could be: <run your bank at home: full node>, <run your wallet on your smartphone: only trust your full-node, maybe a full p2p backup in case your node is down>, <have a vault at home: hardware wallet>
< jonasschnelli>
And I'm looking for a way to decouple the UI from the node.
< jonasschnelli>
And i don't think RPC/JSON would be good.
< phantomcircuit>
jonasschnelli, unfortunately request/response protocols tend to be either unreliable or super complicated
< jonasschnelli>
IMO the only reliable API that bitcoin provides is the p2p "api".
< jonasschnelli>
And it's async. RPC would result in long-polls or pulling-intervals.
< jonasschnelli>
And p2p is already DOS protected.
< GitHub91>
[bitcoin] Speed2016X2 opened pull request #7413: BIP: Block size limit based on average size (Russian) (master...master) https://github.com/bitcoin/bitcoin/pull/7413
< GitHub6>
bitcoin/master 17b5d38 Wladimir J. van der Laan: devtools: show pull and commit information in github-merge...
< GitHub6>
bitcoin/master 0893705 Wladimir J. van der Laan: Merge #7395: devtools: show pull and commit information in github-merge...
< GitHub83>
[bitcoin] laanwj closed pull request #7395: devtools: show pull and commit information in github-merge (master...2016_01_devtool_more_info) https://github.com/bitcoin/bitcoin/pull/7395
< GitHub25>
bitcoin/master 5ed2f16 Andrew C: [devtools] github-merge get toplevel dir without extra whitespace...
< GitHub25>
bitcoin/master 6a5932b Wladimir J. van der Laan: Merge #7402: [devtools] github-merge get toplevel dir without extra whitespace...
< GitHub75>
[bitcoin] laanwj closed pull request #7402: [devtools] github-merge get toplevel dir without extra whitespace (master...dev-tool-fix) https://github.com/bitcoin/bitcoin/pull/7402
< GitHub26>
[bitcoin] laanwj opened pull request #7415: net: Hardcoded seeds update January 2016 (master...2016_01_hardcoded_seeds) https://github.com/bitcoin/bitcoin/pull/7415