Has Dandelion ever been implemented?

[NotATether]

From an old mailing list entry about 8 years ago.

Code:

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

  https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki
  https://github.com/gfanti/bitcoin/tree/dandelion

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

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

  We'd especially like feedback on the implementation details related
to the two points above. The mempool embargo mechanism is tricky,
since it hard to rule out indirect behavior that reveals if a
transaction 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 alternative
approach (bypassing mempool entirely) seems even harder to get right,
and foregoes existing DoS protection.

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

  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 (notes
from gmaxwell that we've mostly incorporated in the current proposal)

Thanks!
-----
Giulia Fanti <gfanti@andrew•cmu.edu>
Andrew Miller <soc1024@illinois•edu>
Surya Bakshi <sbakshi3@illinois•edu>
Shaileshh Bojja Venkatakrishnan <bjjvnkt2@illinois•edu>
Pramod Viswanath <pramodv@illinois•edu>

I came upon this through the Bitcoin Wiki and I think it would be a bandwidth-friendlier alternative for transaction broadacasting than simply syncing an entire node via the Tor network and then relying on that for broadcasting.

There are way more clearnet nodes than Tor nodes anyway.

[PrimeNumber7]

This sounds like a trade-off of sacrificing security in favor of getting marginal levels of privacy.

I am not sure if this has been implemented, but I don't think it is a good idea. There are already plenty of ways to broadcast your transaction without revealing your IP address.

If for some reason, you *needed* to use a node you fully control, and it could not use TOR, you could broadcast your transaction with two of your nodes that are in geographically diverse locations.

[NotATether]

This sounds like a trade-off of sacrificing security in favor of getting marginal levels of privacy.

I don't see how it makes the transaction broadcasting less secure. The raw transaction has already been signed.

[nc50lc]

That should be BIP-0156 in the current BIP list; if not, it has similar goal (and authors)
Link: github.com/bitcoin/bips/blob/master/bip-0156.mediawiki

But it's not in the list of implemented BIPs in the reference client.
List of implemented BIPs by Bitcoin Core: github.com/bitcoin/bitcoin/blob/master/doc/bips.md

[NotATether]

That should be BIP-0156 in the current BIP list; if not, it has similar goal (and authors)
Link: github.com/bitcoin/bips/blob/master/bip-0156.mediawiki

But it's not in the list of implemented BIPs in the reference client.
List of implemented BIPs by Bitcoin Core: github.com/bitcoin/bitcoin/blob/master/doc/bips.md

Thanks.

Why was it not implemented by Core in the end? Performance tradeoffs, or lack of guarantee that a hop to another node could always be found?

[Kruw]

I came upon this through the Bitcoin Wiki and I think it would be a bandwidth-friendlier alternative for transaction broadacasting than simply syncing an entire node via the Tor network and then relying on that for broadcasting.

You don't have to sync your node over Tor to broadcast a transaction over Tor. Wasabi Wallet has had this private broadcast feature forever, and it was just merged into Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/29415

Murch explained why this method is preferable to Dandelion in the Bitcoin Optech podcast:

I think this is better than Dandelion, yes. Basically, Dandelion still had the problem that you were asking your peers to participate in essentially a conspiracy against the network, “Hey, I’m giving you this transaction, but don’t broadcast it, just forward it to someone else”. Of course, the neighbor didn’t know whether they were the first hop or the third hop in this stem phase of Dandelion, but you still leaked the originator of the transaction to at least one peer. In this case, yes, the recipient knows, “Oh, this is an ephemeral new private connection. Clearly, this is coming directly from the originator to me”. But because of how the connection is being made, they can’t actually tell who the originator is in clearnet; they don’t learn the IP address.

So, I think this takes the idea that led to Dandelion, “We want to obfuscate who the originator of a transaction is”, and improves on it by basically just inserting the transaction on some random points on a network until it is properly broadcast. And it gets rid of the concerns with the stem phase, where Dandelion required you to have separate mempools for every peer to facilitate these stem phases. And now, you just remember who you sent a transaction to, but there is no multi-hub, there is no keeping track of who you told about transactions in the stem phase or whether you saw them later. It’s binary basically, “Have I seen the transaction? Then I can broadcast it. Otherwise, I remember who I sent it to”.

...

I have maybe one little follow-up on Dandelion. I didn’t explain very well why it was complicated with mempools on Dandelion. So, when you broadcast a transaction and it has two phases in Dandelion, first the stem phase where every peer just forwards it to one more peer, and then the fluff, where someone randomly then decides to broadcast it. And the problem here was everybody along the way had to basically keep track whom they got the transaction from so they wouldn’t send it back to the same one, and who they sent it to, and then behave differently regarding that transaction until they saw it back to the network. Like, they would pretend not to have seen the transaction. But with this approach that we now actually have in Bitcoin Core, you don’t have to pretend. It’s just as soon as you get it on a network, you use it as if it were a foreign transaction and you had seen it for the first time. And everybody that you broadcast it to just treats it as a new transaction they received. So, there’s none of the special behavior and you don’t have to have extra mempools for every peer.

[nc50lc]

Why was it not implemented by Core in the end?

I'll just point you to this pull request where they aimed to get it implemented in Bitcoin Core.
Link: Dandelion transaction relay (BIP 156) #13947

That's beside the reasons in the post above which is a better alternative.

[ABCbits]

From an old mailing list entry about 8 years ago.
--snip--

I just remember i created this thread many years ago, [Discussion] Dandelion - A protocol to hide transaction origin.

I came upon this through the Bitcoin Wiki and I think it would be a bandwidth-friendlier alternative for transaction broadacasting than simply syncing an entire node via the Tor network and then relying on that for broadcasting.

If you mean initial block download / initial sync when you say "syncing an entire node", IMO you better do it with VPN.

There are way more clearnet nodes than Tor nodes anyway.

Looking at https://bitnodes.io/charts/ which only count reachable node, it's not true. Currently it shows 65% of them use Tor.