Erlay

What Is Erlay?

Erlay is a Bitcoin protocol improvement defined in BIP 330 that redesigns how unconfirmed transactions propagate across the peer-to-peer network. Today, when a node learns about a new transaction, it announces that transaction's ID to every connected peer: a process called flooding. Because most peers already know about the transaction, the vast majority of these announcements are redundant.

Erlay replaces most of this flooding with periodic set reconciliation. Instead of announcing every transaction to every peer, a node announces new transactions to only a small subset of peers and then periodically reconciles its transaction set with the remaining peers using compact sketches. The result is dramatically less bandwidth consumed for the same level of transaction propagation.

The proposal was authored by Gleb Naumenko, Pieter Wuille, Gregory Maxwell, Alexandra Fedorova, and Ivan Beschastnikh. The underlying research was presented at ACM CCS 2019, and the BIP was published in November 2019.

How It Works

Erlay splits transaction relay into two distinct phases: a limited fanout phase and a reconciliation phase.

Phase 1: Limited Fanout

When a node receives a new transaction, it directly announces the transaction ID to a small number of peers: typically one outbound connection plus roughly 10% of inbound connections. This ensures the transaction begins propagating through the network quickly, reaching a broad set of nodes within a few hops.

Phase 2: Set Reconciliation

For all remaining peers, the node does not send individual announcements. Instead, each node maintains a per-connection "reconciliation set": the list of transaction IDs it has received since the last reconciliation round with that peer. Periodically, two peers exchange compact sketches of their reconciliation sets and compute the symmetric difference to identify which transactions one has that the other lacks.

The reconciliation process follows these steps:

1. One peer sends a reconciliation request to the other
2. Both peers compute a sketch of their local reconciliation set using the Minisketch library
3. The requesting peer sends its sketch to the responding peer
4. The responding peer combines (XORs) the two sketches and decodes the result to find the symmetric difference: the set of transaction IDs present in one set but not the other
5. Each peer requests the specific transactions it is missing

The Minisketch Library

At the core of Erlay is Minisketch, an open-source library implementing the PinSketch algorithm (a BCH-code-based secure sketch). The key insight is that sketch size scales with the number of differences between two sets, not the total set size. If two peers differ by only 5 transactions out of thousands, the sketch needed to identify those 5 differences is tiny.

Sketch size is calculated as b × c bits, where b is the element bit-width and c is the capacity (expected number of differences). Sketch creation runs at approximately 5 nanoseconds per element per capacity, making the computational overhead negligible. Minisketch is roughly 49x faster than the reference PinSketch implementation.

// Conceptual sketch reconciliation flow
// Node A and Node B each have a set of transaction short IDs

// 1. Both nodes create a sketch of capacity c
sketch_a = minisketch_create(32, 0, c)
sketch_b = minisketch_create(32, 0, c)

// 2. Each node adds its transaction short IDs to its sketch
for txid in reconciliation_set:
    minisketch_add(sketch, txid)

// 3. Node A sends its serialized sketch to Node B
// 4. Node B combines the sketches (XOR operation)
minisketch_merge(sketch_b, sketch_a)

// 5. Node B decodes to find the symmetric difference
differences = minisketch_decode(sketch_b)

// 6. Each side requests the transactions it is missing

Bandwidth Comparison

Under the current flooding model, transaction relay bandwidth scales as O(nodes × connections). Every peer connection adds a near-full copy of all transaction announcements. Erlay reduces this to approximately O(nodes), because reconciliation sketch sizes depend on set differences rather than total peer count.

At the current default of 8 outbound connections, Erlay saves approximately 40% of total transaction relay bandwidth. If nodes were to increase their outbound connections to 32 (which Erlay makes practical), savings would reach approximately 75%. Estimates suggest this translates to roughly 100 MB per day per node.

Why It Matters

Transaction relay is one of the largest bandwidth consumers for full nodes. As the Bitcoin network grows and transaction volumes increase, the cost of flooding becomes an increasingly significant barrier to running a node, especially for users with limited bandwidth or data caps.

Erlay directly addresses this by making transaction propagation far more efficient. The practical benefits extend beyond raw bandwidth savings:

• Lower barrier to running a full node: reduced bandwidth requirements mean more users can operate nodes on residential internet connections or in bandwidth-constrained environments
• More peer connections without penalty: because bandwidth no longer scales linearly with peer count, nodes can safely maintain more connections, which hardens the network against eclipse attacks and partitioning
• Better decentralization: lower resource requirements for full nodes support a more geographically and economically diverse set of node operators
• Complementary to other optimizations: Erlay works alongside compact block relay (BIP 152), which optimizes block propagation rather than transaction propagation

For layer-2 protocols built on Bitcoin, efficient base-layer transaction relay matters because channel opens, closes, and on-chain settlements all rely on timely transaction propagation. A more robust base layer with broader node participation strengthens the foundation that protocols like the Spark protocol and the Lightning Network build upon.

Use Cases

Enabling Higher Connectivity

The most significant use case for Erlay is enabling nodes to increase their peer count without incurring prohibitive bandwidth costs. Research has shown that higher connectivity makes the network significantly more resistant to partitioning and eclipse attacks, where an attacker isolates a node by controlling all of its peer connections. Under the current flooding model, increasing connections from 8 to 32 would roughly quadruple transaction relay bandwidth. Erlay makes this increase practical.

Running Nodes on Constrained Networks

Node operators in regions with metered internet, mobile data caps, or satellite connections benefit directly from reduced bandwidth. The 40% savings at default connectivity could mean the difference between running a node being feasible or not. This is especially relevant for the growing diversity of node implementations targeting resource-constrained environments.

Improving Transaction Privacy

Under flooding, the first peer to announce a transaction to a node is likely the originator (or close to it), which enables transaction origin analysis. Erlay's reconciliation-based relay makes it harder to determine where a transaction entered the network, because most peers learn about transactions through batch reconciliation rather than direct announcements. This provides a modest improvement to transaction-level privacy.

Implementation Status

Erlay is being implemented incrementally in Bitcoin Core rather than as a single large change:

• The Minisketch library has been integrated into Bitcoin Core as a subtree dependency, with build support and fuzzing tests complete
• The sendtxrcncl negotiation message, which allows peers to signal Erlay support during connection handshake, was merged in October 2022 (PR #23443)
• Erlay status reporting in the getpeerinfo RPC has been merged
• The core reconciliation logic: filling reconciliation sets, handling reconciliation requests and responses: remains under active development and review (tracked in GitHub issue #30249)

BIP 330 has received concept ACKs from multiple reviewers with no NACKs. No official release timeline has been announced, but active development continues as of 2026. The protocol is designed to be backward-compatible: nodes that support Erlay negotiate its use with compatible peers and fall back to flooding with older nodes.

Risks and Considerations

Added Propagation Latency

Because reconciliation happens periodically rather than immediately, Erlay introduces approximately 0.2 seconds of additional propagation latency for transactions that spread via reconciliation rather than fanout. While negligible for most use cases, this tradeoff is worth understanding: faster propagation remains important for time-sensitive scenarios like replace-by-fee races. The limited fanout phase mitigates this by ensuring initial propagation still happens quickly through a subset of peers.

Reconciliation Failures

If the actual number of set differences exceeds the sketch capacity, the reconciliation round fails and the peers must fall back to exchanging full transaction announcements or requesting a larger sketch. The protocol must estimate capacity well to keep failure rates low. In practice, research indicates that short reconciliation intervals keep set differences small and predictable.

Backward Compatibility Period

Until a significant portion of the network upgrades, nodes will maintain both flooding (for non-Erlay peers) and reconciliation (for Erlay peers) simultaneously. During this transition period, bandwidth savings will be proportional to the fraction of peers that support the protocol. This is similar to how compact blocks were gradually adopted across the network.

Protocol Complexity

Erlay adds new message types, per-connection state tracking, and reconciliation scheduling to the peer-to-peer protocol. Each node must maintain reconciliation sets, handle sketch encoding and decoding, and manage fallback logic for failed reconciliation rounds. This added complexity requires careful implementation to avoid introducing bugs in the critical transaction relay path.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.