Dear bitcoin-dev,We've put together a preliminary implementation and BIP forDandelion, and would love to get your feedback on it. Dandelion is aprivacy-enhancing modification to Bitcoin's transaction propagationmechanism. Its goal is to obscure the original source IP of eachtransaction.

The main idea is that transaction propagation proceeds in twophases: first the “stem” phase, and then “fluff” phase. During thestem phase, each node relays the transaction to a *single* peer. Aftera random number of hops along the stem, the transaction enters thefluff phase, which behaves just like ordinary transactionflooding/diffusion. Even when an attacker can identify the location ofthe fluff phase, it is much more difficult to identify the source ofthe stem. Our approach and some preliminary evaluation are explainedin more detail in the BIP. The research paper originally introducingthis idea was recently presented at SIGMETRICS'17.https://arxiv.org/pdf/1701.04439.pdf

Compared to the original paper, our current proposal includesseveral new design ideas, especially:- Stronger attacker model: we defend against an attacker thatactively tries to learn which nodes were involved in the stem phase.Our approach is called "Mempool Embargo", meaning a node that receivesa "stem phase" transaction behaves as though it never heard of it,until it receives it again from someone else (or until a random timerelapses).- Robustness. We think the privacy benefit shouldn't come at theexpense of propagation quality. Our implementation is designed so thatif some node drops the transaction (or when Dandelion is adopted onlypartially), then the fallback behavior is ordinary Bitcoinpropagation.

We'd especially like feedback on the implementation details relatedto the two points above. The mempool embargo mechanism is tricky,since it hard to rule out indirect behavior that reveals if atransaction is in mempool. In the BIP we explain one counterexample,but at least it requires the attacker to get its connections banned.Are there other ways we haven't thought of? We think the alternativeapproach (bypassing mempool entirely) seems even harder to get right,and foregoes existing DoS protection.

We're currently running in-situ benchmark experiments with this codeon testnet and will report on those in this thread if there'sinterest.

Some prior discussion can be found here:- https://botbot.me/freenode/bitcoin-wizards/2017-03-29/?msg=83181866&page=2- https://botbot.me/freenode/bitcoin-wizards/2017-01-18/?msg=79578754&page=2- https://github.com/sbaks0820/bitcoin-dandelion/issues/1 (notesfrom gmaxwell that we've mostly incorporated in the current proposal)

Post by Andrew Miller via bitcoin-devDear bitcoin-dev,We've put together a preliminary implementation and BIP forDandelion, and would love to get your feedback on it. Dandelion is aprivacy-enhancing modification to Bitcoin's transaction propagationmechanism. Its goal is to obscure the original source IP of eachtransaction.

I'm glad to see this out now, so I'm not longer invading the git repouninvited. :)

Post by Andrew Miller via bitcoin-dev- Stronger attacker model: we defend against an attacker thatactively tries to learn which nodes were involved in the stem phase.Our approach is called "Mempool Embargo", meaning a node that receivesa "stem phase" transaction behaves as though it never heard of it,until it receives it again from someone else (or until a random timerelapsess).That is, Alice will not include the embargoed transaction when responding to MEMPOOL requests, and will not respond to GETDATA requests from another node (Bob) unless Alice previously sent an INV to Bob. The embargo period ends as soon as Alice receives an INV advertising the transaction as being in fluff mode.

For example, it's not clear if I can query for the existence of atransaction by sending a conflict. If this doesn't seem problematic,consider the case where I, communicating with you over some privatechannel, send you a payment inside a payment protocol message. Youannounce it to the network and I concurrently send a double spend.Only nodes that were part of the stem will reject my double spend, soI just learned a lot about your network location.

It's also appears clear that I can query by sending an inv andnoticing that no getdata arrives. An example attack in the latter isthat when I get a stem transaction I rapidly INV interrogate theentire network and by observing who does and doesn't getdata I willlikely learn the entire stem path upto permutation.

The extra network capacity used by getdata-ing a transaction youalready saw via dandelion would be pretty insignificant.

I believe the text should be simplified and clarified so just say:

"With the exception of her behavior towards the peer sending in thestem transaction and the peer sending out the transaction Alice'sbehavior should be indistinguishable from a node which has not seenthe transaction at all until she receives it via ordinary forwardingor until after the timeout." -- then its up to the implementation toachieve indistinguishably regardless of what other protocol featuresit uses.

Post by Andrew Miller via bitcoin-devAre there other ways we haven't thought of? We think the alternativeapproach (bypassing mempool entirely) seems even harder to get right,and foregoes existing DoS protection.

I think avoiding the is the most sensible way; and from a softwaremaintenance perspective I expect that anything less will end upcontinually suffering from serious information leaks which are hard toavoid accidentally introducing via other changes.

The primary functionality should be straightforward to implement,needing just a flag to determine if a transaction would be accepted tothe mempool but for the flag, but which skips actually adding it.

Handling chains of unconfirmed stem transactions is made morecomplicated by this and this deserves careful consideration. I'm notsure if its possible to forward stem children of stem transactionsexcept via the same stem path as the parent without leakinginformation, it seems unlikely.

This approach would mostly take additional complexity from the need tolimit the amplification of double spends. I believe this can beresolved by maintaining a per-peer map of the not yet expired vin'sconsumed by stem fowards sent out via that peer. E.g. vin->{timeout,feerate}. Then any new forward via that stem-peer is tested againstthat map and suppressed if it it spends a non-timed-out input anddoesn't meet the feerate epsilon for replacement.

Use of the orphan map is not indistinguishable as it is used for blockpropagation, and itself also a maintenance burden to make sureunrelated code is not inadvertently leaking the stem transactions.

The BIP is a bit under-specified on this transition, I think-- but Iknow how it works from reading the prior implementation (I have notyet read the new implementation).

The way it works (assuming I'm not confused and it hasn't changed) isthat when a new stem transaction comes in there is a chance that it istreated as coming in as a normal transaction.

An alternative construction would be that when a stem transaction goesout there is a random chance that the stem flag is not set (withsuitable adjustment to keep the same expected path length)

For some reason I believe this would be a superior construction, but Iam only able to articulate one clear benefit: It allows non-dandelioncapable nodes to take on the role of the last stem hop, which Ibelieve would improve the anonymity set during the transition phase.

Unrelated:

Has any work been given to the fact that dandelion propagationpotentially making to measure properties of the inter-node connectiongraph? e.g. Say I wish to partition node X by disconnecting all ofits outbound connections, to do that it would be useful to learn whomis connected to X. I forward a transaction to X, observe the firstnode to fluff it, then DOS attack that node to take it offline. WillI need to DOS attack fewer or more nodes to get all of X's outboundsif X supports rapid stem forwarding?