JoinMarket-Org / joinmarket

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

Protocol extention where maker sends address and value of UTXOs in !ioauth #682

Open chris-belcher opened 7 years ago

chris-belcher commented 7 years ago

This is required to be sorted out before better blockchaininterfaces can be made like #653 and #470

Creating an issue for this problem: https://github.com/JoinMarket-Org/joinmarket/issues/470#issuecomment-260671512

Nonverifying wallets are not able to query the utxo set like a full node can. After discussing it a little on IRC it seems probably the best way forward now is to have the maker send the value and address for each UTXO it sends. It's possible they could simply lie about it, but full node takers will still check, the worst that could happen is the transaction will be invalid (so this is a DOS) and makers have an incentive not to do this.

Right now the !ioauth command looks like this (see https://github.com/JoinMarket-Org/JoinMarket-Docs/blob/master/Joinmarket-messaging-protocol.md#private-conversation-in-detail)

!ioauth ulist maker_auth_pub coinjoinA changeA B(mencpubkey) (NS)

We can code a backward-compatible change that adds a list of addresses and values (I haven't tested the backward-compatability but from reading the code it should work)

!ioauth ulist maker_auth_pub coinjoinA changeA B(mencpubkey) addressvaluelist (NS)

Then after we see that almost all makers have updated, we can write new blockchain interfaces like #653 and #470

chris-belcher commented 7 years ago

This opens a DOS where lots of makers announce cheap offers and then send invalid UTXOs to nonverifying-takers who can't tell that the UTXOs are fake, and therefore can't ban the makers.

Two ways for the taker to detect invalid UTXOs:

  1. pushtx() will fail, then the taker could maybe ban all makers. This allows one bad maker to get other makers banned, so this is a DOS because it amplifies the effect.
  2. The other makers will all be running full nodes and could check whether the UTXOs are real. They could send an error message back to the taker with the invalid UTXOs. Trouble is the taker can no more trust them either, they could simply lie and that would be a DOS.