Review of CoinShuffle++.
CoinShuffle is a Bitcoin mixing technique, based on CoinJoin, presented in 2014. CoinShuffle++ is its successor, presented in 2016.
The review is done in a Q&A format. My process of fully digesting the paper was the following:
- Ask questions.
- Read Abstract and ask questions.
- Read Conclusion and ask questions.
- Skim the paper, get familiar with its flow.
- Skim the paper, read interesting parts, look at figures and ask questions.
- Read Introduction, ask questions and take notes for the authors.
- Try to answer questions.
- Read the rest of the paper, try to answer questions and take notes for the authors.
- Read Abstract, Introduction and Conclusion again.
- Skim the rest of the paper, read interesting parts and ask questions.
- Try to answer most questions.
- Send notes, answered and unanswered questions to the authors.
| Abbreviation | Phrase |
|---|---|
| BCM | Byzantine Cycle Mode |
| CoinShuffle | CS |
| CoinShuffle++ | CS++ |
| CCJ | Chaumian CoinJoin |
| ZL | ZeroLink |
| DM | DiceMix |
Right now all Bitcoin mixing technique are mixing in rounds with a common, pre-defined denomination. But it is possible to add additional anonymity by adding additional mixing. An obvious improvement would be to add additional mixing to the change outputs, but there are better ways to do this. I previously attempted to find an optimal algorithm, but I failed.
In CCJ the server can easily build the transaction in an optimal way, but CS++ needs to come to decentralized consensus.
If solely relying on Tor/I2P is allowed it seems to me DM is unnecessary even from a performance point of view, since in order to hide IPs, the scheme should rely on Tor/I2P anyway, therefore DM's speed would not add much if anything. Eg. Tor identity change with new stream happens quite fast. Also I think multiple Tor addresses can be served by one machine, however at this point I'm not sure how likely a connection between them can be exposed or if it's necessary to CS++ in the first place.
No.
ZL is a framework that makes sure round based mixing techniques don't get deanonymized due to other means. CS++ and CCJ can both be used with ZL.
CS++ pros:
- More decentralized, it may even be possible to be built in a fully decentralized way. Decentralization provides censorship resistance.
- Better researched and has higher quality academic specification.
- Its mixing doesn't rely on an external anonymity network, rather it presents its own: DM. However it relies on an anonymity network, but only for IP masking, if this anonymity network fails or isn't implemented in the first place it's not a big deal.
CCJ pros:
- Faster, although it doesn't matter, because the most time will always be spent on to wait for peers.
- Much simpler.
- More interactive feedback can be provided to the user directy pulled from the coordinator.
- Easy to change, newly found implementation flaws rarely require upgrading the whole network, only the coordinator.
Yes, a Bitcoin address to provide fees can be hardcoded into every peer.
Can dynamic information be shown and updated to the user in CS++? (Time waited for peers in the last round, Last round's anonymity set, Time elapsed from the start of the current round, Number of connected peers waiting for more to kick off the round.)
No. DM doesn't remove Tor dependency, just makes it less relevant.
Yes it is ideal, but it is not crucial. Dandelion cannot be used for this, because the IP anonymity set would be the users of all peers, while DM already achives that. While Tor could extend the IP anonymity set to all Tor users.
Building DiceMix over Tor/I2P means is not an obvious task. The vast majority of libraries cannot handle Tor properly, let alone I2P, so it's possible building the communication would take up to half a year, since networking protocols must be implemented from scratch, which is quite a job. (Refer to my half finished Tor Over TCP implementation.)
Building CoinShuffle can take also up to a few months.
However the main problem is everything must be built near perfectly the first time, because fixing bugs is quite hard, and requires the whole network to be upgraded. Of course we've seen already non-production ready implementations, like the authors proof of concept, ShufflePuff or CashShuffle, but a decentralized system cannot be built with the typical startup's minimal time to market mentality, because they are hard to fix later.
DM and CS++.
Most protocols fail to simultaneously address the crucial problems of slot collisions and disruption by malicious peers, while the remaining ones handle f malicious peers with O(f^2) communication rounds.
In this work we present DiceMix, a P2P mixing protocol based on DC-nets that enables participants to anonymously publish a set of messages ensuring sender anonymity and termination. DiceMix avoids slot reservation and still ensures that no collisions occur, not even with a small probability.
Is DM a P2P anonymity network and not a Bitcoin mixing technique? If yes, what's the Bitcoin mixing technique used?
DM is a mixnet, the Bitcoin mixing technique used is CS++.
No, Tor is a third party anonymity proxy.
Mix networks get their security from the mixing done by their component mixes, and may or may not use route unpredictability to enhance security. Onion routing networks primarily get their security from choosing routes that are difficult for the adversary to observe, which for designs deployed to date has meant choosing unpredictable routes through a network. And onion routers typically employ no mixing at all. This gets at the essence of the two even if it is a bit too quick on both sides. Mixes are also usually intended to resist an adversary that can observe all traffic everywhere and, in some threat models, to actively change traffic. Onion routing assumes that an adversary who observes both ends of a communication path will completely break the anonymity of its traffic. Thus, onion routing networks are designed to resist a local adversary, one that can only see a subset of the network and the traffic on it. - Paul Syverson - Why I'm not an Entropist
It can be substituted with a reliable broadcast protocol.
I don't see how, but even if they can, it doesn't matter, most time goes to wait for peers.
That's a fancy way to say it.
It's often overlooked.
Indeed, it's not insignificant if the IP anonymity set consists of real or Tor IPs. From an implementation point of view this opens a can of worms. Yet, I suspect the first version of this can get away with not using Tor.