The Problem With Telling Everyone Everything

Your node gets a transaction. Old model: it shouts to every connected peer immediately, they shout to theirs, and within seconds the whole network knows. Fast. Tidy, even.

Also a privacy disaster.

The first node to broadcast is, statistically, very likely the node that originated the transaction. A passive observer sitting at enough network vantage points doesn't need to break any cryptography. They watch the flood spread, trace it back to its source, and tie a transaction to an IP address through nothing fancier than geometry. The protocol handed them a spotlight and pointed it at the sender.

Erlay is Bitcoin's answer to this. Its fanout phase, the part that still does old-style flooding but does it carefully, is where the interesting engineering lives.

What Erlay Actually Does (The Short Version)

Erlay is a transaction relay protocol proposed by Gleb Naumenko, Pieter Wuille, Gregory Maxwell, Sasha Fedorova, and Ivan Beschastnikh, described formally in a 2019 paper and later codified as BIP 330. The main innovation is replacing most redundant flooding with set reconciliation: peers periodically compare short summaries of their transaction sets and only exchange what's missing. Bandwidth drops dramatically.

But not every transaction goes through reconciliation. A small fraction get fanned out the old way, pushed directly to a handful of peers. That fraction is the fanout phase.

Why keep any flooding at all? Pure reconciliation introduces latency. Transactions propagate in rounds, not waves. For a network that needs to spread information across thousands of nodes quickly enough to be useful, some direct pushing is non-negotiable. The trick is choosing which peers receive the fanout push without handing an observer a map back to the origin.

How the Fanout Phase Selects Peers

This is the mechanical core.

When a node originates or receives a transaction under Erlay, it doesn't push to all peers immediately. It divides its connections into two pools: a small set designated for fanout, and the rest designated for reconciliation. The fanout set is small by design. The current protocol targets roughly the square root of a node's total outbound connections as fanout candidates, though the exact parameter is still being refined in implementation.

For a node with eight outbound peers, a typical default, that means roughly two or three peers receive the transaction via direct push. The rest learn about it through reconciliation rounds.

Which peers get the fanout is where privacy enters the picture. The assignment is not static. It is randomized per transaction, not per session. A node has no fixed "fanout friend" it always pushes to first. Every transaction independently and randomly picks its fanout recipients from the eligible peer pool.

That randomness is load-bearing. I think this is the single most important design decision in the whole protocol. If selection were deterministic, an observer controlling even one peer could learn, over time, that it always hears certain transactions first from node X. Pattern established. Origin inferred. Per-transaction randomization breaks that correlation cold.

A second layer of protection, borrowed from Dandelion (BIP 156), desynchronizes fanout pushes through a short, randomized delay rather than dispatching them the moment a transaction is ready. Two nodes that received the same transaction at nearly the same moment will push it outward at slightly different times, blurring the wavefront an observer would use to triangulate the source. The signal smears like ink in water rather than radiating cleanly from a center point.

A Worked Scenario

Call them Alice and Bob. Both run full Bitcoin nodes with eight outbound peers each. Alice originates a transaction.

Under old flooding: Alice immediately pushes to all eight peers. Each of those pushes to theirs. An observer with connections to four of Alice's eight peers sees the transaction arrive at roughly the same moment from Alice's direction. Source identified with high confidence.

Under Erlay fanout: Alice's node randomly selects two of her eight outbound peers, say peers 3 and 7, as this transaction's fanout targets. She waits a random delay, perhaps 100 to 200 milliseconds, then pushes to those two. Peers 1, 2, 4, 5, 6, and 8 learn about the transaction later, through reconciliation rounds on a fixed schedule.

An observer with connections to Alice's peers now sees something messier. Only two peers got the early push, chosen randomly, so next transaction it might be peers 1 and 5. The observer can't build a reliable origin fingerprint because the signal keeps shifting. Bob, relaying Alice's transaction onward, runs the same process independently. The wavefront diffuses rather than radiates.

Not perfect anonymity. But the cost of origin inference rises substantially, and that is the actual goal.

The Honest Caveat

Erlay's fanout phase is not a silver bullet. Conflating it with a complete privacy solution would be sloppy thinking, and I'd push back on anyone making that claim.

A well-resourced adversary controlling a large fraction of a node's peer connections, say 30% or more, still has significant statistical power. Randomization helps; it doesn't make inference impossible. Naumenko and colleagues were explicit about this in the original paper. Erlay improves on the status quo. It does not eliminate the threat model.

There's also a meaningful distinction between inbound and outbound peers. Erlay's privacy protections are primarily designed around outbound connections, which a node initiates and has some control over. Inbound connections arrive from the outside and could include adversarial peers. A node cannot verify the intent of whoever connected to it, so those connections are handled differently.

Erlay is, as of this writing, still being integrated into Bitcoin Core. The parameter choices, how many fanout peers, how delays are calibrated, remain subject to change as implementation matures. The mechanism described here reflects the protocol design; specific deployed behavior may differ in version details.

That said, the fundamental insight is durable. Randomized, per-transaction peer selection is the right tool for this job. Static selection leaks patterns. Dynamic, random selection doesn't. Ask yourself: when was the last time a privacy problem got solved by making behavior more predictable?

The broader principle travels well beyond Bitcoin. Any gossip network balancing propagation speed against origin privacy faces this same tradeoff. Erlay's fanout design resolves it cleanly: flood just enough to be fast, randomize just enough to be opaque. The elegance is in accepting that flooding can't be eliminated entirely, so you make the flooding itself unpredictable.

Privacy, in network design as in most things, is less about hiding and more about generating noise.