Hi all,

We're writing with an update on the Dandelion project. As a reminder, Dandelion

is a practical, lightweight privacy solution that provides Bitcoin users formal

anonymity guarantees. While other privacy solutions aim to protect individual

users, Dandelion protects privacy by limiting the capability of adversaries to

deanonymize the entire network.

Bitcoin's transaction spreading protocol is vulnerable to deanonymization

attacks. When a node generates a transaction without Dandelion, it transmits

that transaction to its peers with independent, exponential delays. This

approach, known as diffusion in academia, allows network adversaries to link

transactions to IP addresses.

Dandelion prevents this class of attacks by sending transactions over a randomly

selected path before diffusion. Transactions travel along this path during the

"stem phase" and are then diffused during the "fluff phase" (hence the name

Dandelion). We have shown that this routing protocol provides near-optimal

anonymity guarantees among schemes that do not introduce additional encryption

mechanisms.

Since the last time we contacted the list, we have:

 - Completed additional theoretical analysis and simulations

 - Built a working prototype

   (https://github.com/mablem8/bitcoin/tree/dandelion)

 - Built a test suite for the prototype

   (https://github.com/mablem8/bitcoin/blob/dandelion/test/functional/p2p_dandelion.py)

 - Written detailed documentation for the new implementation

   (https://github.com/mablem8/bips/blob/master/bip-dandelion/dandelion-reference-documentation.pdf)

Among other things, one question we've addressed in our additional analysis is

how to route messages during the stem phase. For example, if two Dandelion

transactions arrive at a node from different inbound peers, to which Dandelion

destination(s) should these transactions be sent? We have found that some

choices are much better than others.

Consider the case in which each Dandelion transaction is forwarded to a

Dandelion destination selected uniformly at random. We have shown that this

approach results in a fingerprint attack allowing network-level botnet

adversaries to achieve total deanonymization of the P2P network after observing

less than ten transactions per node.

To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is

assigned a particular Dandelion destination. Each Dandelion transaction that

arrives via this peer is forwarded to the same Dandelion destination.

Per-inbound-edge routing breaks the described attack by blocking an adversary's

ability to construct useful fingerprints.

This iteration of Dandelion has been tested on our own small network, and we

would like to get the implementation in front of a wider audience. An updated

BIP document with further details on motivation, specification, compatibility,

and implementation is located here:

https://github.com/mablem8/bips/blob/master/bip-dandelion.mediawiki

We would like to thank the Bitcoin Core developers and Gregory Maxwell in

particular for their insightful comments, which helped to inform this

implementation and some of the follow-up work we conducted. We would also like

to thank the Mimblewimble development community for coining the term "stempool,"

which we happily adopted for this implementation.

All the best,

Brad Denby <bdenby@cmu.edu>

Andrew Miller <soc1024@illinois.edu>

Giulia Fanti <gfanti@andrew.cmu.edu>

Surya Bakshi <sbakshi3@illinois.edu>

Shaileshh Bojja Venkatakrishnan <shaileshh.bv@gmail.com>

Pramod Viswanath <pramodv@illinois.edu>