Dandelion++: How Bitcoin Can Hide Transaction Origins at the Network Layer

When you broadcast a Bitcoin transaction, your node sends it to every connected peer. Those peers forward it to their peers, and within seconds the entire network knows about it. This flooding pattern is efficient for propagation, but it creates a surveillance opportunity: an adversary running multiple nodes can observe which node relayed a transaction first and link that transaction to an IP address. Dandelion++ is a protocol designed to break that link by fundamentally changing how transactions propagate through the peer-to-peer network before reaching the public mempool.

Why Network-Layer Privacy Matters

Bitcoin privacy is often discussed in terms of on-chain analysis: chain analysis firms clustering addresses, tracing change outputs, and identifying wallet patterns. But the network layer is a separate and often overlooked attack surface. On-chain privacy techniques like CoinJoin and silent payments can obscure the relationship between sender and receiver on the blockchain, but they do nothing to hide who originated the transaction at the network level.

In 2014, Koshy, Koshy, and McDaniel published research at Financial Cryptography (FC 2014) demonstrating that a custom client connected to the Bitcoin P2P network could identify over 1,000 Bitcoin address-to-IP address mappings by analyzing relay patterns over five months. The same year, Biryukov, Khovratovich, and Pustogarov presented a more sophisticated attack at ACM CCS 2014, achieving deanonymization success rates between 11% and 60% depending on stealth level. Their attack required only a few machines and could link transactions to IP addresses even for clients behind NAT or firewalls.

The core problem: Bitcoin’s default transaction relay uses diffusion (flooding), where a node announces a transaction to all its peers near-simultaneously. An adversary running spy nodes throughout the network can triangulate which node broadcast first, linking transactions to IP addresses with high confidence.

How Standard Transaction Relay Works

To understand what Dandelion++ changes, it helps to understand what happens today. When a Bitcoin node creates or receives a new transaction, it validates the transaction against its mempool policy, then announces it to all connected peers using an INV (inventory) message. Peers that want the full transaction respond with GETDATA, and the originating node sends the complete transaction. Those peers then repeat the process with their own connections.

This symmetric diffusion pattern creates a timing signature. The node that originated a transaction will, on average, be the first to relay it. An adversary with connections to many nodes can use timing analysis to identify the originator with statistical confidence. Research has shown that even with Bitcoin Core’s existing random relay delays (Poisson timers added to stagger announcements), the originating node remains identifiable.

The spy node strategy

A surveillance entity connects to as many Bitcoin nodes as possible. For each transaction, it records the timestamp of the first relay from each peer. The peer that consistently relays transactions earliest is likely the originator. With enough connections, the adversary can map transactions to IP addresses for a significant portion of the network. This is not a theoretical concern: it is a documented, practical attack that has been demonstrated in peer-reviewed research.

Dandelion: The First Attempt

The original Dandelion protocol was proposed in 2017 by Shaileshh Bojja Venkatakrishnan, Giulia Fanti, and Pramod Viswanath, published in the Proceedings of the ACM on Measurement and Analysis of Computing Systems (POMACS) and presented at ACM SIGMETRICS 2017. The core insight was elegant: split transaction propagation into two phases.

• Stem phase: the transaction passes through a random chain of nodes, each forwarding to exactly one peer, like a dandelion stem
• Fluff phase: the transaction is broadcast using standard diffusion, spreading symmetrically like dandelion seeds

By the time the transaction enters the fluff phase, it appears to originate from a node several hops away from the actual sender. The adversary sees the fluff origin, not the true origin.

However, the original Dandelion made simplifying assumptions about adversary behavior that did not hold in practice. The Dandelion++ paper, published in 2018 by the same team (expanded to include Surya Bakshi, Bradley Denby, Shruti Bhargava, and Andrew Miller), identified four classes of attacks that broke the original protocol’s guarantees.

Dandelion++: Fixing the Vulnerabilities

Dandelion++ (arXiv:1805.11060), also published at ACM SIGMETRICS 2018, addressed four specific attack categories that undermined the original Dandelion design.

Attacks on original Dandelion

The two-phase mechanism in detail

In Dandelion++, when a node creates a new transaction, it enters the stem phase. The node forwards the transaction to one of its two designated Dandelion relay peers (selected at the beginning of the current epoch). At each subsequent hop, the receiving node makes a random decision: with 90% probability, it continues forwarding along the stem to its own designated relay peer. With 10% probability, it transitions to the fluff phase and broadcasts the transaction using standard diffusion to all peers.

The expected stem length is approximately 10 hops (given the 10% per-hop fluff probability). After those hops, the transaction fans out through normal gossip protocol relay as if it originated from the fluff node.

Epochs and graph rotation

Nodes operate in asynchronous epochs of approximately 10 minutes. At each epoch boundary, a node selects new outbound relay peers and reconstructs its portion of the anonymity graph. This time-limited structure prevents adversaries from learning the relay topology through long-term observation. Even if an adversary identifies a stem path during one epoch, the graph is rebuilt before the next, rendering that knowledge useless.

The embargo fail-safe

Every node that relays a stem-phase transaction starts a randomized embargo timer. If the transaction does not reappear as a fluff-phase broadcast before the timer expires, the node autonomously switches to the fluff phase and broadcasts the transaction through standard diffusion. This guarantees liveness: even if every node along a stem path is adversarial and drops the transaction, it will still propagate.

Why the coin flip matters: The 90/10 stem/fluff probability at each hop is carefully tuned. A higher stem probability provides more privacy (more hops before fluff) but increases propagation delay and the risk of transaction drops. A lower probability reduces privacy gains. The 90/10 split was derived from formal analysis balancing anonymity guarantees against network performance.

Dandelion++ vs. Tor: Complementary Approaches

Running a Bitcoin node over Tor is another approach to network-layer privacy. Bitcoin Core has supported Tor since early versions and added I2P and CJDNS support in more recent releases. These overlay networks hide a node’s IP address from its peers. But Tor and Dandelion++ solve different problems.

Tor protects transport-layer privacy: it prevents your ISP and network observers from seeing that you are running a Bitcoin node or which peers you connect to. But it does not protect against a spy node adversary within the Bitcoin network itself. If an adversary controls multiple Tor-connected peers, the same timing analysis attacks work within the Tor network. Dandelion++ addresses this by making the transaction’s path through the P2P network unpredictable, regardless of the underlying transport.

The strongest configuration combines both: Tor to hide the node’s IP from peers and Dandelion++ to hide which node originated each transaction. Biryukov et al. (2014) demonstrated that Bitcoin’s anti-DoS mechanisms could be exploited to force Tor-using nodes back to clearnet, underscoring why transport-layer privacy alone is not sufficient.

Implementation Status in Bitcoin Core

Despite strong academic foundations, Dandelion++ has not been merged into Bitcoin Core. The primary implementation attempt was PR #13947, opened in August 2018 and closed in July 2019 without merging. The PR implemented BIP 156 (authored by Brad Denby, Andrew Miller, Giulia Fanti, and others), which formalized the Dandelion++ protocol for the Bitcoin network.

Why it was not merged

Bitcoin Core reviewers, including Pieter Wuille and Suhas Daftuar, raised several concerns that proved difficult to resolve.

• Stempool complexity: Dandelion++ requires a second mempool (the “stempool”) to hold transactions during the stem phase. Bitcoin’s existing mempool is already one of the most complex data structures in the codebase, handling RBF, CPFP, transaction chains, and eviction policies. Maintaining a parallel structure with equivalent safety guarantees introduced significant engineering burden.
• DoS attack surface: accepting transactions into the stempool before full mempool validation opens bandwidth and CPU-exhaustion vectors. An adversary could flood stems with invalid transactions, consuming resources across the relay path before the transactions are ever fully validated.
• Privacy leaks from shared state: a stempool shared across inbound peers could inadvertently leak routing information to adversaries connecting from multiple IP addresses.
• Review capacity: Bitcoin Core’s security-critical P2P code has a small pool of qualified reviewers. The PR required deep expertise in both networking code and privacy-preserving protocols, and it competed for review attention with other priorities.

BIP 156 is now formally closed. No active replacement PR exists in Bitcoin Core as of mid-2026.

What Bitcoin Core has done instead

The Bitcoin Core project has prioritized incremental privacy improvements that are easier to review and deploy.

• BIP 324 (v2 P2P encrypted transport): merged in Bitcoin Core 26.0, enabled by default in 27.0. Uses ChaCha20-Poly1305 encryption for all peer-to-peer communication, preventing passive eavesdroppers (ISPs, network observers) from reading Bitcoin P2P traffic. This addresses transport-layer surveillance but does not obscure transaction origins.
• Improved Tor, I2P, and CJDNS support: continuously updated to support overlay network transports.
• Erlay (BIP 330): replaces flood-based transaction relay with a hybrid approach using set reconciliation via Minisketch, reducing relay bandwidth by approximately 40%. Still under active development. Erlay and Dandelion++ are complementary: Erlay could serve as the fluff-phase mechanism while Dandelion++ handles the stem phase.
• Relay timing improvements: various PRs have refined transaction announcement timing to reduce information leakage, including preventing nodes from answering GETDATA for transactions they have not yet announced.

Who Has Deployed Dandelion++

While Bitcoin Core has not adopted Dandelion++, several other cryptocurrency projects have implemented and deployed it in production.

These deployments demonstrate that Dandelion++ is practically implementable. The smaller codebases and more homogeneous node populations of these projects made adoption simpler than in Bitcoin Core, where the P2P layer must handle a far wider range of node configurations, versions, and adversarial conditions.

Relationship to Other Privacy Techniques

Network-layer privacy is one dimension of a larger Bitcoin privacy landscape. Different techniques address different attack surfaces, and they compose rather than compete.

On-chain privacy

CoinJoin breaks the common input heuristic by combining multiple users’ inputs and outputs into a single transaction, making it difficult to determine which input funded which output. PayJoin achieves a similar effect in a two-party payment context. These protocols obscure the on-chain transaction graph, but they do not hide who broadcast the transaction to the network. An adversary could still link a CoinJoin transaction to the IP address that originated it.

Address-layer privacy

Silent payments generate unique, unlinkable addresses for each payment without requiring sender-receiver interaction. This prevents address reuse and makes it impossible for an observer to link payments to a static address. But silent payments protect the receiver’s identity on-chain: the sender’s network-layer exposure remains unchanged.

Routing-layer privacy

On the Lightning Network, onion routing ensures that intermediate routing nodes only know their immediate predecessor and successor, not the full payment path. This is analogous to Dandelion++’s stem phase: each hop has limited knowledge about the overall route. Lightning’s blinded paths extend this further by hiding the receiver’s node identity from the sender.

How these layers compose

A privacy-conscious Bitcoin user might combine multiple techniques: Dandelion++ (or Tor) to hide the transaction’s network origin, CoinJoin to obscure the transaction graph, and silent payments to prevent address linking. Each layer addresses a distinct attack vector, and weakness in one layer does not compromise the others.

Technical Challenges and Open Questions

The stempool dilemma

The fundamental engineering challenge is the stempool: a data structure for holding transactions during the stem phase. In the current Bitcoin Core architecture, the mempool serves as the canonical set of unconfirmed transactions. Introducing a stempool creates questions about how to handle replace-by-fee conflicts, CPFP chains, transaction dependencies, and eviction policies in two parallel structures. Getting these interactions wrong could introduce DoS vectors or consensus-relevant bugs.

Partial deployment

Dandelion++ provides the strongest privacy guarantees when all nodes on the network support it. In a partially deployed scenario, stem-phase transactions that reach a non-supporting node will be broadcast immediately via standard diffusion, shortening the effective stem length. The embargo mechanism ensures that transactions still propagate, but the privacy benefit degrades proportionally to the fraction of non-supporting nodes.

Light clients and SPV

SPV clients and mobile wallets typically connect to a small number of full nodes rather than participating in the P2P network directly. These clients submit transactions through their connected peers, who become the effective originator in terms of network-layer analysis. Dandelion++ does not directly benefit SPV clients, though it could be extended with a client-mode protocol where the client’s trusted node initiates a stem phase on its behalf.

Off-Chain Alternatives: A Different Approach

Network-layer privacy techniques like Dandelion++ address a problem inherent to on-chain transaction broadcast. Off-chain protocols take a fundamentally different approach: by moving transactions off the public network entirely, they sidestep the broadcast problem altogether.

The Lightning Network’s onion-routed payments are never broadcast to the full network. Only the nodes along a payment route see the payment, and each node only sees its immediate neighbors in the route. This provides inherent network-layer privacy that does not require any modification to the base-layer relay protocol.

Spark takes this further. Transfers on Spark happen entirely off-chain through statechain key rotations. No transaction is broadcast to the Bitcoin P2P network during a Spark transfer, meaning there is no originating node, no relay pattern, and no timing signature for an adversary to analyze. The network-layer privacy problem that Dandelion++ addresses simply does not exist for off-chain Spark transfers.

Complementary models: Dandelion++ improves privacy for transactions that must touch the base layer (funding transactions, channel opens, unilateral exits). Off-chain protocols like Spark and Lightning avoid the base layer for routine transfers. The strongest privacy posture uses both: Dandelion++ for necessary on-chain activity, off-chain protocols for everything else.

What Comes Next

Several developments could revive interest in Dandelion++ for Bitcoin or provide alternative solutions to the same problem.

• Erlay adoption: if Erlay is merged, it changes how the fluff phase works. Rather than flooding, transactions would be reconciled via set difference. This could simplify the integration of a Dandelion++-style stem phase, since the fluff phase would already be non-trivially different from today’s diffusion.
• Cluster mempool: Bitcoin Core’s ongoing cluster mempool refactor restructures mempool internals around transaction clusters. While not directly related to Dandelion++, a cleaner mempool architecture could make a stempool implementation more tractable.
• Alternative designs: the Clover protocol (proposed in 2021) avoids building explicit propagation graphs entirely, claiming comparable privacy with simpler node-local logic. It could be easier to implement in Bitcoin Core, though no PR exists.
• Other networks: Bitcoin Cash published CHIP 2025-01 in January 2025 proposing Dandelion++ integration, indicating continued interest in the broader Bitcoin ecosystem.

For developers building on Bitcoin today, the practical recommendation is to combine available tools: run nodes over Tor or I2P, use BIP 324 encrypted connections, and leverage off-chain protocols for routine transactions. Developers building wallets and payment applications on Spark benefit from inherent network-layer privacy for off-chain transfers, while on-chain activity (deposits, withdrawals) can be routed through Tor-connected nodes for additional protection.

For a deeper look at how different privacy techniques interact across the Bitcoin stack, see our full Bitcoin privacy landscape overview.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.