Erlay: How Bitcoin's New Relay Protocol Cuts Node Bandwidth by 40%

Running a Bitcoin node today costs more bandwidth than it should. The culprit is transaction relay: every time a node learns about a new transaction, it announces that transaction to every one of its peers. With dozens of connections, the same 32-byte transaction ID gets sent and received over and over, consuming bandwidth that serves no purpose after the first copy arrives. Erlay is a protocol upgrade defined in BIP 330 that replaces most of this redundant flooding with a technique called set reconciliation, cutting transaction relay bandwidth by roughly 40%.

The protocol was designed by Gleb Naumenko and Pieter Wuille, with foundational research published at ACM CCS 2019. While full Erlay support has not yet shipped in a Bitcoin Core release, key building blocks are already merged, and a complete implementation is under active review. This article explains how Erlay works, what it changes about Bitcoin's gossip protocol, and why the bandwidth savings matter for the long-term health of the network.

Why Transaction Relay Is Expensive

Bitcoin's current relay mechanism is called transaction flooding. When a node receives a new transaction, it creates an INV (inventory) message containing the transaction's identifier and sends that message to every connected peer that has not already announced the same transaction. Each INV message costs at least 32 bytes for the txid alone, plus protocol overhead.

A default Bitcoin Core node maintains 8 full-relay outbound connections and accepts up to 125 inbound connections. In the worst case, a single transaction generates well over 100 redundant announcements across the network, each carrying essentially the same information. The Erlay paper found that these redundant INV messages consume bandwidth roughly equivalent to the size of the transactions themselves: approximately 220 bytes per announcement versus around 250 bytes for a typical transaction.

The redundancy problem: In prototype testing described in the Erlay paper, transaction announcements consumed approximately 42 MB of bandwidth for nodes with default connectivity. Erlay reduced this to roughly 15 MB, a saving that compounds across every node in the network.

This overhead has a real consequence: it makes running a full node more expensive on metered connections, discourages operators from increasing their peer count, and limits the network's ability to improve its topology against attacks like eclipse attacks.

How Erlay Works

Erlay does not eliminate flooding entirely. Instead, it introduces a hybrid approach: limited flooding over a small subset of connections, combined with periodic set reconciliation for the rest. The result is that most peers still learn about new transactions quickly, but the bandwidth cost no longer scales linearly with the number of connections.

Limited Flooding

Under Erlay, a node floods new transactions only to its outbound connections to well-connected, publicly reachable nodes. For a default node, this means flooding to roughly 8 peers rather than all 125+. These outbound peers are the most likely to be well-positioned in the network graph, so flooding to them provides fast initial propagation. Erlay uses a diffusion interval of 1 second for outbound connections, compared to Bitcoin's standard 2-second interval, to compensate for the reduced flood set.

Set Reconciliation

For all remaining connections, Erlay replaces per-transaction announcements with periodic set reconciliation. Every 16 seconds (a tunable parameter), a node initiates reconciliation with one of its peers by cycling through them in a predetermined order. Rather than sending a list of every transaction it knows about, the node sends a compact sketch: a mathematical summary of its transaction set.

The receiving peer computes its own sketch and combines the two (via XOR) to produce a sketch of the symmetric difference: the set of transactions that one side has but the other does not. This difference sketch can then be decoded to identify the specific missing transactions, which are requested individually.

Minisketch and PinSketch

The sketch computation relies on libminisketch, an optimized C library developed by Pieter Wuille, Gregory Maxwell, and Gleb Naumenko. Minisketch implements the PinSketch algorithm, a BCH-code-based set reconciliation scheme that is more bandwidth-efficient than alternatives like Invertible Bloom Lookup Tables (IBLTs). PinSketch achieves the same bandwidth efficiency as CPISync but with quadratic decoding complexity instead of cubic, making it significantly faster in practice.

To keep sketches compact, Erlay uses 32-bit short transaction IDs computed with SipHash-2-4 using a shared salt negotiated during the connection handshake. The sketch size scales with the number of differences between two peers' transaction sets, not the total number of transactions either side knows about. In a well-connected network, two peers that reconcile every 16 seconds will typically differ by only a handful of transactions, keeping sketches extremely small.

Why PinSketch over IBLTs: IBLTs (used in compact blocks) work well when the number of differences is known in advance. PinSketch is more bandwidth-efficient when differences are small and variable, which describes the transaction relay use case precisely.

Bandwidth Savings in Detail

The headline figure from the original Erlay paper is a roughly 40% reduction in transaction relay bandwidth for nodes with default connectivity (8 outbound peers). Subsequent experiments by Sergi Delgado in 2025 refined these estimates: flooding to 8 outbound peers achieved approximately 35% savings, while flooding to 12 peers yielded around 45% savings (though with increased propagation latency).

The most important row in that table is bandwidth scaling. Under the current protocol, every additional peer connection costs roughly 32 bytes per transaction in announcement overhead. Under Erlay, reconciliation peers add almost no marginal bandwidth, because sketch sizes depend on set differences, not peer count. This changes the economics of node connectivity entirely.

Latency Tradeoffs

Erlay introduces a modest increase in transaction propagation latency. Simulations in the original paper measured an additional 2.6 seconds on average, bringing typical propagation from around 3.15 seconds to 5.75 seconds. In prototype testing, the difference was smaller: 1.85 seconds versus 2.05 seconds.

This tradeoff is acceptable for several reasons. Bitcoin's 10-minute block time means transactions are not time-critical in the way blocks are. A few extra seconds of propagation delay does not meaningfully affect confirmation times. Blocks themselves continue to propagate through compact block relay and high-bandwidth relay, which are unaffected by Erlay. The protocol only changes how unconfirmed transactions spread through the mempool.

Enabling More Peer Connections

The practical impact of Erlay goes beyond saving bandwidth on existing connections. By decoupling bandwidth cost from peer count, Erlay makes it feasible for nodes to maintain significantly more connections without increasing their resource footprint. The Erlay paper estimates that nodes could safely increase to at least 16 outbound connections at no additional bandwidth cost.

Why More Connections Matter

Bitcoin's security depends on nodes maintaining an accurate view of the network. An eclipse attack works by monopolizing all of a victim's peer connections, isolating them from honest nodes and feeding them a false view of the blockchain. The more outbound connections a node makes, the harder this attack becomes: an attacker must control more IP addresses and more nodes to fill every connection slot.

Currently, the bandwidth cost of additional connections discourages operators from increasing their peer count. Erlay removes this disincentive. A node running Erlay could double its outbound connections and still use less total bandwidth than a node running pure flooding with the current default.

Privacy Benefits

More connections and reconciliation-based relay also harden the network against timing analysis. Under pure flooding, an adversary monitoring multiple nodes can estimate where a transaction originated by observing which node announced it first. Set reconciliation batches announcements into periodic intervals, making it harder to correlate timing with transaction origin. This complements other privacy improvements like Dandelion++, which specifically targets transaction origin obfuscation.

Implementation Status in Bitcoin Core

Erlay's implementation in Bitcoin Core has progressed incrementally since 2019. Two foundational components are already merged, while the full reconciliation logic remains under active review.

What Is Already Merged

The Minisketch library was integrated into Bitcoin Core as a subtree in November 2021 via PR #23114. This provides the set reconciliation primitives that Erlay needs. The library is configured for 32-bit field elements, matching Erlay's short transaction ID size.

The sendtxrcncl message (PR #23443) was merged in October 2022. This is the handshake message that peers exchange during connection setup to signal Erlay support. Nodes that both send sendtxrcncl will use reconciliation for transaction relay; nodes that do not support it fall back to standard flooding seamlessly.

What Is Still Under Review

The full reconciliation logic, including reconciliation set management and the actual sketch exchange, has been through several iterations. Gleb Naumenko's original PR (#21515) and its predecessors laid the groundwork, and Sergi Delgado (sr-gi) opened a comprehensive implementation in PR #35591 in June 2026. Bitcoin Core developers discussed an Erlay redesign at an in-person meeting in May 2026, and the implementation continues to evolve. No specific release version has been announced.

Progress is tracked in GitHub issues #28646 and #30249.

Technical Deep Dive: The Reconciliation Protocol

Understanding the full reconciliation cycle helps clarify how Erlay achieves its savings. Here is the sequence of events when two Erlay-enabled peers reconcile.

Connection Setup

During the version handshake, both peers send sendtxrcncl messages indicating their willingness to use reconciliation. This message includes a salt value used for computing short transaction IDs via SipHash-2-4. Both peers combine their salts to derive a shared secret that determines how transaction IDs map to 32-bit short IDs.

Between Reconciliations

Each node maintains a reconciliation set per peer: a list of transactions that the node would have announced via INV under the old protocol but instead defers for the next reconciliation round. Transactions announced through limited flooding (to outbound peers) are not added to reconciliation sets for those peers.

The Reconciliation Round

Every 2 seconds, a node selects the next peer in its reconciliation schedule. The initiating node computes a PinSketch sketch over the short IDs in its reconciliation set for that peer and sends it. The receiving peer computes its own sketch, XORs the two to obtain the symmetric difference, decodes the result, and requests any missing transactions. Both peers then clear their reconciliation sets for this connection.

If the number of differences exceeds what the sketch can decode (because the sketch was sized for an estimated difference count), the peers fall back to exchanging full transaction ID lists for that round. This fallback ensures correctness at the cost of one round's bandwidth savings.

Impact on Node Operators

Erlay is particularly relevant for operators running nodes on constrained connections: residential ISPs with data caps, mobile or satellite links, or cloud instances billed by bandwidth.

Metered and Mobile Connections

A full Bitcoin node can consume several gigabytes of bandwidth per day, with transaction relay representing a significant fraction. Reducing relay overhead by 40% lowers the cost of participation for operators in regions where bandwidth is expensive or capped. This directly supports censorship resistance: the cheaper it is to run a node, the more people will do it, and the harder the network becomes to attack or censor.

Pruned and Lightweight Nodes

Pruned nodes already reduce storage requirements by discarding old block data. Erlay complements this by reducing ongoing bandwidth requirements. Together, these optimizations make it increasingly practical to run a validating node on hardware as modest as a Raspberry Pi with a standard home internet connection.

Erlay in the Context of Bitcoin P2P Improvements

Erlay is part of a broader effort to improve Bitcoin's peer-to-peer layer. Several related upgrades target different aspects of network efficiency and security.

BIP 324's encrypted transport and Erlay's efficient relay are complementary: encryption prevents ISPs and network-level observers from inspecting or tampering with P2P traffic, while Erlay reduces the volume of that traffic. Together, they improve both the privacy and the economics of running a Bitcoin node.

Why This Matters for Bitcoin Layer 2s

Layer 2 protocols like Spark, Lightning, and statechains depend on a healthy, decentralized base layer for their security guarantees. When users need to settle on-chain or broadcast exit transactions, they rely on a well-connected network of validating nodes to propagate and confirm those transactions promptly.

Every optimization that makes nodes cheaper to run strengthens this foundation. A network with more full nodes is harder to eclipse, harder to censor, and faster at propagating the settlement transactions that Layer 2 users depend on. Erlay's bandwidth savings directly support the economic viability of running the base layer infrastructure that protocols like Spark's statechain model rely on for security.

Challenges and Open Questions

Erlay is not without tradeoffs and unresolved design decisions.

Latency Sensitivity

While the 2.6-second average increase in propagation delay is acceptable for most purposes, it could matter for miners engaged in fee sniping or for services that depend on rapid mempool awareness. Mining nodes may choose to maintain a higher flooding ratio to minimize the delay, which the protocol supports through configurable parameters.

Reconciliation Tuning

The 16-second reconciliation interval and the choice of how many peers to flood versus reconcile are tunable parameters. Sergi Delgado's 2025 experiments showed that different configurations produce different bandwidth-latency tradeoff curves. Finding the right defaults requires real-world deployment data, which will only come once Erlay ships in a Bitcoin Core release and sees significant adoption.

Adoption Curve

Erlay is a peer-to-peer protocol change, not a consensus change. It does not require a soft fork or any kind of network-wide activation. Nodes can adopt it independently, falling back to standard flooding with peers that do not support it. However, bandwidth savings only materialize when both sides of a connection support Erlay. Full network-wide benefits depend on gradual adoption as nodes upgrade.

Conclusion

Erlay addresses one of the oldest inefficiencies in Bitcoin's networking layer. By replacing redundant transaction flooding with Minisketch-based set reconciliation, it cuts relay bandwidth by roughly 40%, makes higher peer counts practical, and improves the network's resistance to eclipse attacks. The foundational libraries and signaling messages are already merged into Bitcoin Core, with full reconciliation logic under active review.

For node operators, Erlay means lower costs. For the network, it means more nodes and better connectivity. For Layer 2 protocols built on Bitcoin, it means a stronger, more resilient base layer. Developers interested in tracking Erlay's progress can follow the Bitcoin Optech Erlay topic page or review the open pull requests linked above. Those building on Bitcoin Layer 2 infrastructure can explore Spark's developer documentation to see how base layer improvements translate to better Layer 2 experiences.

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.