Post
Topic
Re: CoinJoin: Bitcoin privacy for the real world
by
AdNarim
on 18/07/2014, 03:23:39 UTC
I have an idea about a way to perform a decentralized Coinjoin so that individual participants are unable to map inputs to outputs - without the need for an anonymity network or blinded signatures.

As a disclaimer, although I have experience programming I am not well-practiced in cryptography, so forgive me if I make any egregious mistakes and waste everyone’s time.

Given the IP addresses and public keys for all N Coinjoin participant nodes, I envision the following onion routing protocol (inspired by what is used in Tor):

1.   Decide upon a random path which visits every node once and ends up back at our node.

2.   Using Onion Routing, send a multi-level encrypted message along this path. Each node by using its private key to decrypt the message will be able to see where the message was supposed to originate from, the bitcoin addresses to be used as inputs, and where to send the message to next. The rest of the message will only be able to be further decrypted by the next destination. When the message gets back to us, it should have visited every node in the path.
See: http://en.wikipedia.org/wiki/Onion_routing

3.   Same protocol, but with output addresses (can be done in parallel with the input addresses).

4.   Same protocol, but with our signature of the completed transaction.

5.   Broadcast transaction.


In theory, each node will be unable to tell from what node the input and output addresses originated. However, I see several serious issues with this proposal, and would welcome even more critique:

  • Timing Attacks: If a node receives the message early in the process, it is more likely that that the sender owns the associated addresses. This may be mitigated through random delays or other, more clever schemes.
  • Message Size: A node may be able to analyze the size of the message to determine how far along it is. To counter this, a randomly-sized allotment of junk data should be included in the inner-most message.
  • Slow: this protocol takes N time, as the message must be forwarded to each node.
  • DDOS: What is to stop some other node from screwing everyone over? It is possible to see if our message was tampered with (using random numbers, accumulating counters, etc.), but it would still be difficult to make the protocol resistant to malicious nodes mucking everything up and wasting everyone’s time.
  • Sybil Attacks: You’re pretty much screwed. Tor has similar issues, this is one thing you really can’t do anything about (other than favoring IP addresses that are likely to be in physically separate locations)
  • Other stuff: It’s probably out there, I just can't think of it at the moment.

Well, what about the positives? Assuming all the negative obstacles are surmountable:

  • Inputs are not linked to IP addresses.
  • Outputs are not linked to IP addresses.
  • Inputs are not linked to outputs any more than can be determined from looking at the finalized transaction.
  • No anonymity network required. This is important as P2P over, say, Tor is a pain.
  • No reconnecting required. You are not required to meet up with the same nodes again.
  • If you are behind a NAT router or firewall blocking inbound connections, you can hire an open node as a proxy. As only you have access to your private key, you can have this node forward/receive your messages without worrying about it snooping (granted, it can still cause as much trouble as the other nodes, and you probably have to compensate the proxy owner by including a small transfer in your transaction).