You're running a Bitcoin node. A new transaction arrives. Before your node does anything with it, a quiet capability negotiation has already determined whether this peer gets a compact sketch of your mempool state or just a raw inventory announcement. That decision was made during the version handshake, before any transaction data existed to leak. Most node operators never think about it. They probably should.
The Problem That Made Erlay Necessary
Bitcoin's pre-Erlay gossip protocol is blunt to the point of waste. A node learns about a new transaction and immediately fans out `inv` messages (inventory announcements) to every connected peer. Each peer checks whether it already knows that transaction and, if not, fetches it. At eight outbound peers per node and a busy mempool, that's a lot of redundant chatter. Researchers Gleb Naumenko, Pieter Wuille, Gregory Maxwell, Sasha Fedorova, and Ivan Beschastnikh put a number on it: roughly 44% of Bitcoin's total bandwidth was spent on transaction relay, and the vast majority of those `inv` messages were redundant.
Erlay's answer is set reconciliation. Instead of announcing every transaction immediately, nodes accumulate a short window's worth of transaction IDs, encode them into a data structure called a PinSketch (a BCH-code-based invertible Bloom filter), and exchange just that sketch. The receiver decodes the difference. For a typical pair of well-connected nodes whose mempools overlap heavily, the sketch is tiny. The bandwidth saving across the whole network lands at roughly 84% on transaction relay.
But encoding your mempool state into a sketch and handing it to a peer creates a privacy surface that the pure `inv` approach does not. A sketch tells a peer something about which transactions you hold. The peer selection logic exists precisely to control who gets to learn that.
How Erlay Picks Reconciliation Peers
Not every peer gets the sketch treatment.
Erlay divides a node's connections into two classes. For a small number of outbound peers, chosen during connection setup, the node uses low-fanout flooding: it still sends `inv` messages the old way, immediately, to keep transactions propagating quickly across the network. Think of these as the express lanes, narrow but fast. The BIP-330 specification (the formal proposal for Erlay) targets roughly one or two such flooding peers per node, though implementations may tune this.
Every other peer, including most outbound connections and all inbound connections, becomes a reconciliation peer. With these peers, transactions are held back, accumulated in a local sketch, and reconciled on a schedule. The current design proposes reconciliation rounds every few seconds.
Here is the part that actually matters for privacy. The selection of which outbound peers get flooding versus reconciliation is not content-driven. The node negotiates Erlay support during the version handshake: if both sides signal `sendrecon`, they become reconciliation peers. No mempool contents are consulted. The decision is purely capability-based and happens before any transaction data is exchanged.
If a node instead chose reconciliation peers based on mempool overlap, picking peers who seemed to share the most transactions, the selection process itself would leak information about what the node holds. Erlay avoids this by making the choice structural. That is not a minor implementation detail. It is the load-bearing beam of the whole privacy argument.
The Sketch Exchange: What It Does and Doesn't Reveal
Consider a worked example. Call the two nodes Alice and Bob. Alice's mempool holds 3,000 transactions. Bob's holds 2,980 of the same ones, plus 15 that Alice doesn't have. Alice has 35 that Bob doesn't. The symmetric difference is roughly 50 elements.
Alice sends Bob a PinSketch sized to decode, say, 100 differences, estimating conservatively. The sketch runs to maybe 800 bytes. Bob decodes it, learns the 35 transaction IDs Alice holds that he doesn't, and requests those transactions. He also identifies the 15 he has that Alice lacks and sends those over.
What does Bob actually learn about Alice's mempool? The symmetric difference. Not her full set. A PinSketch encodes only the XOR-based difference structure; it is not a compressed inventory of all of Alice's transactions. An adversary sitting at Bob's position sees roughly 50 transaction IDs they didn't already know Alice held. Compare that to the old approach, where Alice would have fired `inv` messages for all 35 unique transactions immediately, to every peer, with no batching.
Are you running a well-synced node sitting above 85% mempool overlap with your peers? The sketch you emit is tiny and reveals almost nothing that wasn't already common knowledge on the network.
Timing Attacks: A Narrower Problem Than Advertised
One persistent concern with any batched relay scheme is whether delayed announcement makes it easier for a network observer to map which node originated a transaction. Counterintuitively, Erlay improves on the status quo here. Under the old flooding model, a transaction's first appearance propagates outward in a wave, and timing analysis can often trace that wave back to its source node. With Erlay, the batching and per-peer reconciliation scheduling blur the wave considerably. Transactions from different originators get mixed into the same sketch. The reconciliation schedule introduces jitter that is, in practice, protective.
The remaining concern is targeted and specific: a well-resourced adversary who connects to your node as many peers simultaneously could request reconciliation with each, compare the resulting sketches, and attempt to infer your unique mempool contents over time. Erlay's defense is limiting inbound connections that receive sketch data and rate-limiting reconciliation requests. The protocol does not solve Eclipse attacks (those are addressed by separate connection management logic, and conflating the two obscures both problems), but it does not make them worse.
One thing people consistently misread about Erlay: it is not a privacy protocol in the sense that Dandelion++ is. Dandelion++ obscures a transaction's origin by routing it through a stem phase before broadcasting. Erlay is a bandwidth protocol that happens to carry better privacy properties than what it replaces, as a structural consequence of how sketches work. Treating it as a privacy silver bullet is a mistake. Treating it as irrelevant to privacy is equally wrong, and in practice the second error shows up more often in technical commentary.
The real achievement is that the peer selection mechanism manages to cut bandwidth by roughly 84% without giving any single peer a meaningful window into your mempool's composition. That outcome follows directly from one disciplined design choice: the reconciliation-peer decision is made before any transaction data exists to leak, and the sketch's information content is bounded to differences rather than totals. For a protocol change that touches every node on the network, getting both goals from a single structural commitment is the kind of engineering that tends to age well.