Improving Baselayer Privacy with Dandelion++
Every once in a while, someone digs out a long discarded Bitcoin improvement proposal and annoys the fuck out of people much smarter than them. This is that.
Everybody knows: Bitcoin is not privacy software. While we are limited in adding privacy features to Bitcoin on the baselayer to avoid breaking fundamental assumptions – such as anonymized amounts – there are still improvements we can make which complicate the surveillance of interactions on the Bitcoin network. One such improvement is Dandelion++.
Dandelion is a propagation protocol designed to obfuscate where a Bitcoin transaction originated. To understand its benefits and trade offs, we first need to understand how Blockchain Surveillance firms ascribe transaction ownership in Bitcoin's peer-to-peer network.
By default, a Bitcoin full node establishes eight outbound connections to other peers on the network to distribute transactions between mempools. In Bitcoin's current propagation design, these transactions are sent simultaneously to all outbound peers, forwarding transactions across the network. This propagation process is called diffusion.
To determine where a transaction originated, Blockchain Surveillance firms operate so-called supernodes. A supernode attempts to establish as many connections to nodes on the peer-to-peer network as possible, and by doing so is able to tell where a transaction first appeared. This enables Blockchain Surveillance firms to tie your transactions to your node's IP address.
Dandelion prevents such deanonymization attacks because it does not announce transactions to all outbound peers. Instead, using Dandelion, a node chooses a single outbound peer to relay its transaction to. This peer chooses another single outbound peer, who chooses another single outbound peer, and so on and so forth. This is called the 'stem phase'.
Once the transaction has gained enough plausible deniability – i.e. is far enough away from their origin in the graph – a node which did not create the transaction relays it to all its outbound peers, and routing continues as usual. This is called the 'fluff phase'.
The easiest way to think about Dandelion routing may be to compare it to a Sneakernet. Say Alice wants to make a public announcement, but does not want the public to know that the message came from her. Alice may now choose to leave her message with Bob, who shares her message with Carol, who shares her message with David.
David can now announce Alice's message to the public, but only knows that the message came from Carol. Carol knows that she gave the message to David, but only knows that the message came from Bob. Bob knows that he gave the message to Carol and that the message came from Alice, but in our best case scenario where everyone uses Dandelion, has to assume that Alice may have gotten the message from someone else as well.
Dandelion essentially provides similar anonymity to the Bitcoin network as an Onion routed protocol, as relayers are only definitively aware of the hop before and the hop after them. So why not use Tor for all Bitcoin peer-to-peer traffic?
While desirable from a privacy perspective, there are many considerations that influence a node operator's decision to utilize the Tor network for transaction propagation, the main consideration being that it takes a certain level of expertise. The aim of Dandelion is to provide transaction origin privacy for anyone in the Bitcoin network regardless of technical capabilities.
Dandelion was first proposed for Bitcoin routing on the Bitcoin mailing list in 2018, and has since been improved in Dandelion++, Dandelion Lite and Clover, and has been implemented in privacy first currencies and protocols like Monero and Mimblewimble. On Bitcoin, the implementation of Dandelion was rejected due to Denial of Service concerns. Additionally, Dandelion may require the implementation of a stempool – meaning a second mempool dedicated to Dandelion stem phase propagation.
Maintaining Bitcoin's mempool is already a difficult task, and the development of a second mempool to maintain in addition may not be favorable from a complexity point of view. But times have changed from when the benefit of hiding transaction origins seemed small in light of development overhead.
Today, as even non-custodial Bitcoin service operators are starting to be held accountable for broadcasting transactions originating from undesirable jurisdictions and activities, revisiting the implementation of Dandelion++ may now prove fundamental to preserve the censorship resistance of the Bitcoin network.
