[bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

Neudecker, Till (TM) till.neudecker at kit.edu
Thu Jul 5 14:50:26 UTC 2018


Dear Bradley,

maybe I’m a little bit late to the discussion, but I’d also like to share some thoughts:

* Could you elaborate on the reasoning behind choosing the periodic route shuffling interval to be around 10 minutes? I guess that there is some tradeoff between making intersection attacks possible by choosing a too small interval, and making graph-learning attacks possible by choosing a too large interval. Intuitively, this interval should depend on the number of forwarded Dandelion transactions, because these are the events that leak information, and not the absolute elapsed time. On the other hand, making the interval dependent on the number of processed transactions would allow an active adversary to trigger route shuffling by sending Dandelion transaction to specific peers, which could enable intersection attacks...

* Speaking of active adversaries: Adversaries could send a large number of transactions to selected peers - either by creating the transactions on their own, or by relaying (Dandelion) transactions observed by the adversary’s peers to the selected peer. Could this allow the adversary to launch fingerprinting attacks on the selected peer by comparing the observed propagation of the transactions relayed through the peer to other transactions observed?

* If an adversary performs a black-hole attack (i.e., drops Dandelion transactions), and if the adversary is able to identify the diffusion source, reconstruction of parts of the anonymity graph (i.e., the part between the diffusion source and the last peer before the black-hole) might be possible. I understand that the adversary does not gain much from the knowledge of the anonymity graph, but it nonetheless helps the adversary.

* Out of personal interest: Inferring Bitcoin’s network topology is hard. I think it’s wise to assume a strong adversary that has perfect knowledge of the topology, but can you make any statements on the sensitivity of the adversary’s precision and recall regarding imperfect topology knowledge?


--Till


From: bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Bradley Denby via bitcoin-dev
Sent: Monday, June 4, 2018 10:30 PM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

Hello all,

We now have an arXiv preprint of our latest findings available, which provides additional details regarding Dandelion: https://arxiv.org/pdf/1805.11060.pdf

Note that Dandelion's precision guarantees are at the population level, while the recall guarantees can be interpreted as individual guarantees. Expected recall is equivalent to the probability of an adversary associating a single transaction with a given source.

Since these guarantees are probabilistic, a node cannot be sure whether all of its peers are monitoring it. Dandelion does not protect against these adversaries, and individuals who are worried about targeted deanonymization should still use Tor.

One way to conceptualize Dandelion is as a "public health" fix or an "anonymity vaccination." Higher adoption leads to greater benefits, even for those who are not using Tor. Individuals who adopt Dandelion benefit because their transactions make at least one hop before diffusing (or more as adoption increases).

Nevertheless, the probabilistic nature of the guarantees means that they are not absolute. We have shown that any solution based only on routing cannot be absolute due to fundamental lower bounds on precision and recall.

Thank you to Eric Voskuil, Pieter Wuille, Suhas Daftuar, Christian Decker, and Tim Ruffing for the recent feedback!

On Thu, May 10, 2018 at 8:59 AM, Bradley Denby <bdenby at cmu.edu> wrote:
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 at cmu.edu>
Andrew Miller <soc1024 at illinois.edu>
Giulia Fanti <gfanti at andrew.cmu.edu>
Surya Bakshi <sbakshi3 at illinois.edu>
Shaileshh Bojja Venkatakrishnan <shaileshh.bv at gmail.com>
Pramod Viswanath <pramodv at illinois.edu>



More information about the bitcoin-dev mailing list