search

JoinMarket-Org / joinmarket

CoinJoin implementation with incentive structure to convince people to take part
398 stars 119 forks source link

Single trusted node blockchain interface #470

Open chris-belcher opened 8 years ago

chris-belcher commented 8 years ago

Fleshing out this idea in more detail: https://github.com/JoinMarket-Org/joinmarket/issues/55#issuecomment-165994649

The user would give a single ip address and host to JoinMarket that would connect to a network node controlled by the user and synchronize it's wallet using BitcoinJ-style bloom filters. This would have the same security, privacy and trustless properties as running a full node on the same machine but would solve other problems too. Such as:

  1. Tails users find it very difficult to sync a full node over tor. This feature would allow them to point their JoinMarket to a .onion full node controlled by them either on another of their machines or a VPS.
  2. Full nodes are very annoying to start up and shut down. After having been switched off even overnight it takes an irritating amount of time to sync to the network again and be able to make transactions. With this feature a user could have a full node permanently on in their own home (on a raspberry pi?) and point their JM to it over LAN.

It is much easier to set up a network node than to set up something like an Electrum server, so I think this could increase the adoption of full-nodes-as-wallets.

Two problems/issues I can think of.

  1. The bitcoin p2p protocol doesn't expose the estimatefee function.
  2. Care must be taken when broadcasting transactions so attackers that connect to every single node on the network don't see the IP address of the full node.

Needless to say, the bloom filter can have a very very low false positive rate, because bloom filters are useless for privacy anyway and it would just eat up bandwidth.

However a better alternative to all this may be to simply tunnel JSON-RPC over ssh or tor and get the same thing.

chris-belcher commented 8 years ago

Third benefit: user experience with sync'ing is much better with bloom filters, much better than using "bitcoind -rescan" The user can download blocks quickly containing only their transactions, the script can increment the address index with respect to the gap limit, so only one pass is needed.

Fact is, if there's something Mike Hearn really thought about that was user experience.

chris-belcher commented 8 years ago

Here is some code I was playing with that could be helpful to anyone working on this

https://gist.github.com/chris-belcher/493551782452ff7cf6336dec760e1f1e https://gist.github.com/chris-belcher/1f1fee0b39f023d7bd04dc6e5b722359

The p2p networking code should be somewhat modular so it can be reused for #503 and https://github.com/JoinMarket-Org/joinmarket/issues/55#issuecomment-184165679

chris-belcher commented 7 years ago

This and #653 have the serious problem that they can't query the UTXO set, which is required to be a taker.

In recv_txio() and add_signature() any arbitrary UTXO that the makers send must be queried for their script and amount. In make_commitment() only the UTXOs already in the taker's own wallet must be queried, if the joinmarket wallet kept track of UTXO confirmations then that code could be modified to use wallet.unspent instead of query_utxo_set().

To reduce this need for maintaining the UTXO set for the taker, we could modify the protocol so that the maker sends proof of the UTXO's value and script along with the UTXOs.

This means these features can't be coded unless the protocol is modified first.

chris-belcher commented 7 years ago

As discussed on IRC, the maker could send the entire transaction hex, but that doesn't prove the UTXOs are unspent. Without that, a malicious maker could use it to DOS a taker who wouldn't even know which maker sent them a fake UTXO.

chris-belcher commented 7 years ago

One way to make "Single trusted node blockchain interface" work is to wait for bip151 and consequences to mature. A possible extension for after bip151 is a p2p version of estimatefee, we could ask for or implement a p2p version of query-utxo-set.

Another way to make both of these features work is to wait for delayed txo commitments to mature. That would allow proofs to be made that a utxo really is unspent that the maker could send to the taker.

chris-belcher commented 7 years ago

This could be done by getting the user to specify a p2p address AND json rpc address. The p2p connection can quickly sync the wallet, and the json rpc connection to the full node can query the UTXO set (avoiding the need to do #682 with all its problems) and also json rpc can do estimatefee.