Glossary

Dandelion Protocol

A P2P relay protocol that obscures the originating IP address of a Bitcoin transaction using stem-and-fluff propagation.

Key Takeaways

  • The Dandelion protocol hides which node originated a transaction by splitting relay into two phases: a "stem" phase that forwards along a single random path, and a "fluff" phase that broadcasts normally across the peer-to-peer network.
  • Dandelion++ improved on the original design by using a 4-regular anonymity graph and per-inbound-edge routing, making it resistant to graph-learning attacks, intersection attacks, and black-hole attacks that could compromise the original scheme.
  • Despite strong theoretical guarantees, Dandelion++ has not been merged into Bitcoin Core. It is deployed in Monero and Grin, while Bitcoin users who want IP-level privacy still rely on Tor.

What Is the Dandelion Protocol?

The Dandelion protocol is a network-layer privacy technique designed to prevent adversaries from linking Bitcoin transactions to the IP addresses of the nodes that created them. It was first proposed in 2017 by researchers at the University of Illinois at Urbana-Champaign and formalized in BIP 156.

By default, Bitcoin uses diffusion-based relay: when a node creates a transaction, it announces it to all connected peers, who relay it to all of their peers. This creates a spreading pattern that radiates outward from the originator. A well-connected surveillance node can observe which peer first relayed a transaction and use timing analysis to identify the source IP address. Research has shown that an adversary with roughly 50 connections to each reachable node can deanonymize the origin of about 11% of all transactions.

Dandelion solves this by introducing a two-phase relay mechanism. In the first phase (the stem), the transaction travels privately along a single chain of nodes. In the second phase (the fluff), it is broadcast normally. By the time the transaction reaches the broader network, observers cannot determine how many stem hops occurred or which node started the chain.

How It Works

Dandelion splits transaction propagation into two distinct phases, named after the parts of a dandelion seed head: a thin stem followed by a diffuse fluff.

Stem Phase

When a node creates a new transaction, instead of broadcasting it to all peers, it sends it to a single randomly selected peer called the Dandelion relay. That relay node flips a biased coin: with 10% probability (q = 0.10), it transitions the transaction to the fluff phase; with 90% probability, it forwards it to the next relay in the stem. This continues until a node's coin flip triggers the fluff transition.

With a fluff probability of 10% per hop, the expected number of stem hops before the transition is 10. Each hop moves the transaction further from the originator in the network graph, making it progressively harder for an observer to trace back to the source.

Fluff Phase

Once a node's coin flip triggers the transition, the transaction is broadcast via normal diffusion to all of that node's peers. From this point, propagation looks identical to standard Bitcoin relay. The node that initiates the fluff phase is not the originator, so surveillance nodes observing the broadcast pattern are tracing back to the wrong source.

Fail-Safe Embargo

To prevent transactions from being lost if a stem-path node goes offline or maliciously drops the transaction, each relay node sets an embargo timer (typically 180 seconds). If the transaction does not appear in the node's mempool via normal relay before the timer expires, the node broadcasts it directly via diffusion. This ensures liveness without sacrificing privacy under normal conditions.

Pseudocode

A simplified view of the Dandelion relay logic at each node:

function onReceiveStemTransaction(tx, inboundPeer):
    if tx already in mempool or stempool:
        return  // already known

    add tx to stempool
    start embargoTimer(tx, 180 seconds)

    // Flip biased coin: 10% chance to fluff
    if random() < 0.10:
        broadcastToAllPeers(tx)   // fluff phase
    else:
        relay = getDandelionRelay(inboundPeer)
        sendStemTransaction(tx, relay)  // continue stem

function onEmbargoExpired(tx):
    if tx not in mempool:
        broadcastToAllPeers(tx)   // fail-safe fluff

Dandelion++ Improvements

The original Dandelion proposal assumed that all nodes follow the protocol honestly, each node generates exactly one transaction per observation window, and the entire network runs Dandelion. In practice, none of these assumptions hold. Dandelion++ (published in 2018 at ACM SIGMETRICS) addresses these weaknesses with several key changes.

4-Regular Anonymity Graph

The original Dandelion constructs a line graph (2-regular) for the stem phase: each node has one outbound relay, forming simple chains. An adversary who controls even a few nodes on the stem can learn the graph structure. Dandelion++ replaces this with a random approximate 4-regular graph: each node selects two outbound Dandelion relay peers. The more complex topology makes the adversary's state space exponentially larger, defeating graph-learning attacks.

Per-Inbound-Edge Routing

In Dandelion++, each inbound peer is mapped to a specific Dandelion relay destination. All transactions arriving from the same inbound peer follow the same stem path. This prevents a fingerprinting attack where an adversary sends distinct transactions from multiple connections and observes which relay paths they take, gradually mapping the anonymity graph.

Epoch-Based Reshuffling

The Dandelion relay graph is reshuffled every epoch (approximately 10 minutes on average). This limits the window during which an adversary can perform intersection attacks: observations from one epoch provide no information about the routing topology in the next.

Attacks Addressed

AttackOriginal DandelionDandelion++
Graph-learningVulnerable: line graph is easily mappedResistant: 4-regular graph has exponentially larger state space
IntersectionVulnerable: repeated observation narrows candidatesMitigated: epoch reshuffling and independent coin flips
Black-holeTransactions can be silently droppedEmbargo timer forces fluff after timeout
Partial deploymentAssumes 100% adoptionProvides privacy even with partial adoption

Comparison With Other Privacy Approaches

Default Bitcoin Relay (Diffusion)

Standard Bitcoin transaction relay broadcasts to all peers immediately. This is fast and reliable but leaks timing information. A surveillance node connected to many peers can observe which node first announced a transaction and infer that it is likely the originator. Dandelion++ breaks this correlation by ensuring the transaction first travels through an unpredictable stem path before entering diffusion, so the first node an observer sees is not the creator.

Tor

Tor provides strong anonymity by routing all network traffic through a separate overlay network with multiple layers of encryption. However, Tor adds significant latency, requires explicit user configuration, and can be blocked by some Bitcoin nodes. Dandelion++ is designed as a complement to Tor, not a replacement: it provides network-wide baseline privacy with minimal overhead (a few seconds of added propagation delay), while Tor provides stronger individual-level protection against targeted adversaries and ISP-level surveillance.

Erlay

Erlay is a separate relay protocol improvement focused on reducing bandwidth, not privacy. Erlay uses set reconciliation to minimize redundant transaction announcements between peers. While both Dandelion++ and Erlay modify how transactions propagate through the peer-to-peer network, they address different problems and could potentially be deployed together.

Implementation Status

Despite its theoretical strength, Dandelion++ has had a complicated path to real-world deployment across Bitcoin clients.

Bitcoin Core

A pull request (PR #13947) was opened in August 2018 to implement BIP 156 in Bitcoin Core. It was closed in July 2019 without being merged. Key concerns included potential DoS vulnerabilities related to the stempool (a holding area for stem transactions), unclear handling of transaction chains where child transactions depend on unconfirmed stem parents, and risks of information leakage through the stempool itself. A follow-up issue (#20203) in October 2020 revisited Dandelion++ but was also closed. As of 2026, Dandelion++ is not implemented in Bitcoin Core.

Monero

Monero was the first major cryptocurrency to ship Dandelion++, merging it in April 2020. The implementation adds only a few seconds of propagation delay and integrates with Monero's existing privacy features (ring signatures, stealth addresses).

Grin

Grin (a MimbleWimble implementation) deploys a simplified Dandelion++ variant using a 2-regular anonymity graph instead of a 4-regular one. Its parameters include a 600-second epoch, 180-second embargo timeout, and 10% fluff probability.

Why It Matters

IP-address deanonymization is one of the most practical threats to Bitcoin user privacy. Even if a user employs CoinJoin or other on-chain privacy techniques to obscure the transaction graph, their node's IP address can still be linked to specific transactions through network-level observation. This information can be used for targeted surveillance, chain analysis enrichment, or even physical attacks.

Dandelion++ provides what researchers call "anonymity inoculation": if enough nodes adopt the protocol, even users running older software benefit because the diffusion patterns of the entire network become harder to analyze. This herd-immunity property makes it particularly valuable as a network-wide upgrade rather than a per-user tool.

For Bitcoin layer-2 protocols, network-layer privacy is equally important. Nodes participating in protocols like Lightning channels or off-chain systems reveal IP addresses when broadcasting on-chain settlement transactions. A protocol like Dandelion++ would protect those IP addresses at the base layer, complementing higher-layer privacy mechanisms like onion routing for payment forwarding. For a deeper technical analysis, see the research article on Dandelion and network-level privacy.

Risks and Considerations

Partial Adoption Weakens Guarantees

Dandelion++'s privacy depends on a critical mass of nodes running the protocol. If only a small fraction of the network supports it, stem paths are short (because non-Dandelion nodes immediately fluff), and adversaries can more easily identify the originator. Unlike Tor, which benefits individual users regardless of network-wide adoption, Dandelion++ is most effective as a near-universal upgrade.

Stempool Complexity

Transactions in the stem phase must be held in a separate stempool rather than the regular mempool. This introduces complexity: child transactions that depend on unconfirmed stem parents need special handling, fee estimation becomes harder when stem transactions are not yet publicly visible, and the stempool itself could leak information if not implemented carefully. These engineering challenges were a primary reason Bitcoin Core's implementation attempt stalled.

Propagation Delay

The stem phase adds propagation latency: with 10 expected hops, each requiring a network round trip, transactions may take several seconds longer to reach the full network. For most use cases this is negligible, but applications that depend on rapid mempool visibility (such as replace-by-fee monitoring or real-time fee estimation tools) could be affected.

Not a Complete Privacy Solution

Dandelion++ protects against network-level deanonymization by passive observers, but it does not protect against ISP-level or AS-level adversaries who can observe all traffic entering and leaving a node's network connection. It also provides no on-chain privacy: transaction amounts, addresses, and the UTXO graph remain fully transparent. Users needing comprehensive privacy should combine Dandelion++ with Tor for network-layer protection and techniques like CoinJoin or silent payments for on-chain privacy. For a broader view of the privacy landscape, see the research article on Bitcoin privacy in 2026.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.