Last lecture described mixers, but as the lecturer notes there were some flaws with the design. Honestly, this was a dry lecture in terms of the descriptions and content.
Questions answered in this Post:
- What are some issues with centralized mixers?
- What is CoinJoin?
- What are some implementations of CoinJoin?
- What is a side channels that the lecturer has alluded to?
Cons for using centralized mixers, pros for decentralized
The lecturer brings up several points. First, there is a inherent bootstrapping problem. For a mixer to be successful and create a large anonymity set, they need to have a large number of users. To get users you need to have a god reputation. This is not the case for decentralized mixers because individuals are banding together. As long as there is sufficient interest, mixing can just occur. Second, there is less trust involved and Arvind mentions that you can guarantee no theft. Dependent on how you structure the decentralized protocol, theft can be prevented. No one user is sending Bitcoins. Also, there may be more anonymity with this method. Lastly, it’s more aligned with Bitcoin given that it is a decentralized method.
CoinJoin
The protocol that does this decentralized mix is called CoinJoin. CoinJoin was developed by Greg Maxwell who is a core Bitcoin developer. Coinjoin is a method for bitcoin transaction compression which aims to improve privacy by discarding unnecessary information. Ok, bitcoinwiki doesn’t really explain too much. Investopedia’s definition is a little better. An anonymization strategy that protects the privacy of users when they conduct transactions and requires multiple parties to sign jointly on an agreement to mix their coins when doing separate Bitcoin transactions.
High level explanation of CoinJoin
According to the lecturer, several users come together for a single Bitcoin transaction, and combines all their inputs (he suggests they should be of equivalent value). All the signatures for each of the inputs are entirely separate so a single user does not have to hold the private keys. This means that the users can have a randomized ordering for the transaction. In addition, this was only a single round of mixing and multiple rounds should take place. So outside users may be able to tell that it is a CoinJoin transactions but will not know the internal specifics. The mixing principles discussed from the previous lecture also need to be used.
More lower level algorithm in a list
- Find peers who want to mix (group of like minded people neew to find each other)
- Exchange input/output addresses
- Construct transaction (only a single person does this)
- Send it around, collect signature (Before signing, each peer checks if her output is present: security property)
- Broadcast the transactions
Open Questions for CoinJoin
- How to find peers?
Arvind suggests using an untrusted server which does add engineering complexity. - Is there a security risk that peers know your input-output mapping?
Arvind mentions that as long as there is diversity in the individuals running nodes, it should be ok. It is possible that a single adversary creates numerous sybils such that every sybil is part of every Coinjoin and thus is able to learn the input-output mapping. Thus this would be a problem that is not present in centralized mixes because those can have reputations. The proposed solutions is just a Strawman solution meaning that it’s just a draft version that people can improve. The proposed solution is disconnecting the inputs and outputs via Tor. That leads to a better solution which is having a special-purpose anonymous routing mechanism. These exist under the special term, Decryption Mixnets. - Can there be denial of service attacks?
Yes, one of the nodes can always choose not to sign the transaction. In addition, someone can remove their coins prior to the Coinjoin transaction being written to the blockchain and thus force a double spend attack. Arvind’s solution is to add some fee to prevent people from doing this arbitrarily. He proposed using proof of work, proof of burn (fidelity bonds), server kicks out malicious participants, or Cryptographic “blame” protocol (Coin Shuffle)
Current Implementation of Coinjoin
What is a side channel, high-level flows?
The example is Alice receiving set bitcoin each week as income and then transferring 5% to a retirement account. This kind of pattern is one that is very visible on a blockchain. To prevent this, Mike Hearn proposed merge avoidance. Thus, a receiver provides multiple output addresses and sender avoids combining the different inputs.
Wrap Up
Which of these is NOT an advantage of Coinjoin over centralized mixes?
- Built-in protection against denial-of-service attacks