Your IP Address Was Always Part of the Transaction
You hit send. The wallet confirms. You assume the only thing you've exposed to the world is a string of cryptographic data, anonymous by design, unconnected to any name or address. What actually happens is this: the moment your node announces that transaction to its peers, those peers can log your originating IP address with reasonable confidence. The transaction hasn't touched a block explorer. It hasn't been confirmed. But network-level surveillance tools, the kind academic researchers and blockchain analytics firms have built and documented in peer-reviewed literature, can triangulate your source node by watching which peer announced the transaction first and to how many others simultaneously.
Dandelion is the protocol designed to break that triangulation. Proposed under BIP 156, it works by splitting propagation into two distinct phases before standard gossip flooding begins.
The Stem and the Fluff
The name comes from the plant. Hold a dandelion clock up: one thin stem, then an explosion of seeds in every direction. The protocol mirrors that geometry deliberately.
When a node creates or receives a transaction in the stem phase, it doesn't broadcast to all peers. It forwards to exactly one randomly selected peer. That peer does the same. One hop, one direction. The transaction travels in a straight, quiet line through the network for a random number of hops, typically somewhere in a range of roughly ten to twenty, though the exact count is probabilistic rather than fixed. No simultaneous multi-peer announcement. Just a whisper passed from one node to the next, leaving no bloom of timing data for an adversary to read.
At some point along the stem, a node flips the probabilistic coin, roughly a ten percent chance per hop, and enters the fluff phase. Now it broadcasts normally: to all peers at once, flooding the network the way Bitcoin always has. From any outside observer's vantage point, the transaction simply appears at that fluff node. The origin is somewhere back up the stem, but the stem left no simultaneous multi-peer fingerprint to triangulate from.
A concrete scenario makes this precise. Alice's node in Frankfurt originates a transaction. Under standard gossip, she announces it to eight peers at once; a surveillance node among those peers sees the announcement timestamp, compares notes with other surveillance nodes, and identifies Frankfurt as the likely source within seconds. Under Dandelion, Alice's node passes the transaction to one peer in Amsterdam. Amsterdam passes it to one peer in Warsaw. Warsaw passes it to one peer in Seoul. Seoul flips the coin, decides to flood, and announces to all its peers. The network sees Seoul first. Alice is three hops removed from the apparent origin, and no multi-peer timing attack can reach back through a single-file stem to find her.
Why Standard Flooding Is a Privacy Disaster
The technical term for the standard Bitcoin gossip mechanism is diffusion propagation. Every node that receives a transaction adds a small random delay and then relays to all connected peers. The randomisation helps at the margins. It does not solve the core problem: the first node to announce to multiple peers simultaneously is almost certainly the origin.
Researchers at the University of Illinois demonstrated, in work published around 2014, that a passive adversary controlling roughly thirty percent of network nodes could correctly identify the source IP of a transaction the majority of the time. The attack is called transaction graph inference combined with first-spy estimation. No cryptography breaks. The adversary simply watches network traffic.
Dandelion doesn't make this attack impossible. It makes it substantially harder. The stem phase means the adversary sees only a single-peer relay chain, not a bloom of simultaneous announcements, and even controlling some stem nodes yields only one hop forward and one hop back, never the full origin.
The Honest Tradeoffs
Dandelion has real costs. Glossing over them would be a disservice to anyone actually evaluating the protocol.
Latency first. The stem phase adds propagation delay, with ten to twenty single-hop relays adding seconds before miners see the transaction. In a network where block confirmation averages ten minutes, a few extra seconds is usually irrelevant. For time-sensitive use cases, it is worth knowing.
The stem is also a single point of failure for censorship. A malicious node in the stem path can simply drop the transaction. Under standard flooding, one dropped relay barely matters because several peers have already received it. Under Dandelion's stem phase, one drop silences the transaction entirely. The protocol addresses this with a timeout: if a node that forwarded along the stem doesn't eventually see the transaction arrive via normal flooding within a certain window, it re-broadcasts directly. That is a fallback, not a guarantee, and in genuinely adversarial conditions the distinction matters.
The third tradeoff is the one most commentary skips, and it is the most important one. Dandelion protects the network-level origin, not the blockchain-level origin. Your transaction's inputs still link to previous outputs. Chain analysis firms work primarily at the blockchain layer, tracing UTXO ownership across the ledger. Dandelion does nothing for that. It is a narrow privacy tool for a specific threat: IP-to-transaction correlation. Treating it as something broader is a mistake, and proponents who imply otherwise are doing the protocol no favors.
Think of Dandelion as insulation in your walls. It stops a specific kind of heat loss. It does not replace the furnace, the windows, or the roof.
What Got Deployed, and What Didn't
BIP 156 proposed Dandelion in 2017. Dandelion++, an improved variant addressing stem-phase deanonymisation attacks present in the original design, followed in academic literature. Monero implemented Dandelion++ in its own network before Bitcoin did, which stands as a concrete deployment precedent worth citing when the conversation turns to feasibility.
For Bitcoin specifically, Dandelion has remained in proposal and experimental status longer than many anticipated. The Bitcoin Core development process is deliberately conservative, and rightly so: a networking change that affects propagation reliability requires extensive testing and broad consensus among contributors who do not agree easily. The censorship-via-stem-drop concern is legitimate in adversarial conditions, and the fallback mechanism adds real complexity to a codebase that already carries substantial surface area.
So where does that leave things? Lightning Network nodes, with their own privacy considerations around channel announcements and routing, sit adjacent to this problem but operate under entirely different propagation rules, which means Dandelion's fate in the base layer doesn't resolve the broader question.
The protocol's elegance is genuine. A two-phase propagation model that borrows its geometry from a common garden weed and solves a documented deanonymisation vector without touching consensus rules is clever engineering, full stop. Whether Bitcoin's network eventually adopts it broadly is a separate question from whether the mechanism itself is sound.
It is sound. The implementation question is just harder than the design question. In distributed systems, that asymmetry is almost always true, and Bitcoin has never been the exception to it.