Dandelion++ (BIP156)

A tx broadcast privacy enhancement. Without Dandelion, tx broadcast to all your peers immediately = first peer with chain analytics can infer your IP.

Mechanism

Two phases, run over an anonymity graph that is rebuilt every ~10 min on average (an "epoch"). Routing is fixed per epoch, not drawn per transaction.

Stem phase (anonymity)

Each node picks two of its outbound peers as Dandelion destinations (DANDELION_MAX_DESTINATIONS = 2) and maps every inbound peer to one of them.
A stem tx arriving on a given inbound peer always leaves via the same destination for the whole epoch ("per-inbound-edge" routing). Picking the next hop at random per transaction instead is what enables the fingerprint attack BIP156 avoids.
Expected stem length is 1/q — ~10 hops at BIP156's q = 10%.

During stem, only the chain of forwarders sees the tx.

Fluff phase (broadcast)

BIP156: before relaying, a node SHOULD convert the Dandelion tx into a typical tx with probability q = 10% — a coin flip per transmission.
The Dandelion++ paper instead fixes the role per node, per epoch (diffuser or relayer, from a hash of the node's own identity and the epoch number), so the outcome does not depend on the transaction.
A fluffing node invs to all its peers; from there the tx propagates network-wide via standard gossip.

Privacy benefit

Original sender IP hidden among the stem hop pool.
Chain analyst sees the tx first arrive from a "fluffer", not the origin.
Coordinated chain-analytics nodes have to guess which fluff position was the source.

Implementation status

BIP156 dates from 2017 (Assigned: 2017-06-09 in the BIP header); the Dandelion++ paper is the 2018 item.
Never adopted by Bitcoin Core. BIP156 is listed with status Closed in the BIPs repo README (checked September 2026); the mainline tx relay path is still plain inv flooding.
The only Bitcoin implementation was the BIP156 reference fork of Core (dandelion-org/bitcoin), never merged upstream. Outside Bitcoin, Grin and Monero implement Dandelion++ natively (both present on master, checked September 2026). btcsuite/btcd carries no Dandelion code, commits or issues (checked September 2026).
Core shipped a different answer to the same problem instead — see Private broadcast below.

Why it was never adopted

Adds latency to broadcast (10-30 seconds typical).
Requires coordinated stem peers; if attacker controls many peers, can defeat.
Limited measured privacy gain (still some attribution possible via timing).

Private broadcast (Bitcoin Core 31.0+)

Core 31.0 (19 April 2026) added -privatebroadcast, a boolean node option, default false (checked on master, September 2026). When enabled, txs submitted via sendrawtransaction are broadcast over short-lived connections through Tor or I2P only, and are not put in the local mempool first.

Two privacy properties, per the 31.0 release notes:

The originator's IP address is never known to the recipients.
Two otherwise unrelated txs from the same originator are not linkable — a separate connection per transaction is used.

Introspection/control RPCs, also new in 31.0:

getprivatebroadcastinfo — lists txs currently being privately broadcast.
abortprivatebroadcast — drops matching txs from the private broadcast queue.

Constraints (from init.cpp on master, September 2026):

Txs submitted through the wallet are not affected; the option only covers sendrawtransaction.
Startup fails if neither Tor nor I2P is reachable.
Incompatible with -connect (private broadcast must open its own connections to randomly chosen Tor/I2P peers); use -maxconnections=0 -addnode=... instead.
Warns if -proxyrandomize=0, since Tor circuits for private broadcast may then correlate with other Tor connections.
At most 64 concurrent private broadcast connections (MAX_PRIVATE_BROADCAST_CONNECTIONS); further ones pause.

Upgrade note: 31.0 leaked the originator IP — under certain circumstances connections were made over clearnet rather than the enabled privacy network. Fixed in 31.1 (July 2026). Do not rely on -privatebroadcast on 31.0.

Workarounds in production

Beyond (or without) -privatebroadcast, best practice for broadcast privacy:

Broadcast over Tor (onlynet=onion) — defeats IP correlation.
Use a relay service (mempool.space "submit" via Tor).
Run your own node — eliminates third-party attribution.

Tor-only setups achieve stronger broadcast privacy than Dandelion++ would have in practice.

bitcoin-privacy-dandelion