Erlay
Erlay is a proposed Bitcoin transaction-relay protocol, specified in BIP 330, that replaces most flooding of inv announcements with periodic set reconciliation. Peers exchange a compact sketch of the transaction identifiers each has seen and recover the symmetric difference, so that each transaction is not announced once per peer. The design was published by Gleb Naumenko, Pieter Wuille, and collaborators (ACM CCS 2019). Full Erlay is not enabled in a released Bitcoin Core version.
Flooding cost
On the current gossip network, a node that accepts a new transaction sends an inv to most of its peers, who request the transaction with getdata if they do not already have it. The scheme is simple and latency-efficient, but the same transaction identifier is sent many times. Bandwidth per connection therefore grows with the number of peers. That cost discourages raising outbound connectivity, which is otherwise desirable for eclipse-attack resistance and for keeping the network well connected as it grows. Erlay's stated goals are to cut that redundant bandwidth (the original paper estimated on the order of 40% of announcement bandwidth in typical settings) and to make additional connections cheap enough that nodes can afford more of them.
Set reconciliation
BIP 330 introduces a reconciliation protocol. After the usual version handshake, peers that support Erlay send a sendtxrcncl message advertising parameters. Each peer maintains a reconciliation set of wtxid (witness transaction identifiers) that it would have flooded. At scheduled intervals the peers exchange a Minisketch sketch of that set. Minisketch is an efficient implementation of PinSketch-style set reconciliation over a finite field: a sketch of size proportional to the expected number of differences lets both sides recover the identifiers that only one of them has. Missing transactions are then requested with ordinary getdata and enter the mempool like any other relayed transaction.
Flooding is not eliminated. A small amount of fanout is retained so that a transaction still reaches the network quickly, after which reconciliation heals the remaining gaps. If a sketch is too small for the actual difference, an extension round can enlarge it, or the peers fall back to flooding that interval. The original “full Erlay” design folded flooding and reconciliation into every ordinary transaction-relay connection and tried to guess, per transaction, which mode to use. That policy logic became a large patch. In 2026 Bitcoin Core developers discussed a simpler alternative: leave existing full-relay connections unchanged and add a smaller number of reconciliation-only connections that carry little traffic unless the node's normal peers are unhelpful. Reconciliation-only links would then act as a partition-resistance backup rather than as a replacement for flood relay. Which of those shapes, if any, ships is not settled. Minisketch itself is merged as a library. The sendtxrcncl signaling message has also been merged. The remaining work is the reconciliation state machine, set management, and the associated tests.
Bitcoin Core does not reconcile transactions with Erlay in a stable release. Work is tracked in the Bitcoin Core repository (including the Erlay project tracking issue and draft pull requests for a full implementation). Other node software has not independently deployed BIP 330 as a production relay protocol. Compact blocks (BIP 152) remain the deployed bandwidth reduction for blocks; Erlay addresses transaction announcements. Related transport work such as BIP 324 (v2 P2P encrypted transport) is separate from Erlay's set-reconciliation design.
Minisketch capacity must be chosen for the expected difference between peers' reconciliation sets. Underestimating capacity forces extension rounds or a flood fallback for that interval. Overestimating wastes bandwidth on oversized sketches. BIP 330 parameters negotiated in sendtxrcncl let peers agree on salt, quantum, and related timing knobs before reconciliation begins.
Status
Deployment work in Bitcoin Core has proceeded through prototypes and project tracking rather than a released default. Partial fanout designs try to keep latency close to flooding while still cutting duplicate inv traffic. Until Erlay ships, operators who want more outbound peers pay the full flooding bandwidth cost that BIP 330 is meant to reduce. Compact blocks continue to handle block bandwidth separately. Until set reconciliation ships broadly, bandwidth per extra outbound peer remains roughly proportional to transaction announcement rate, which keeps default outbound limits conservative relative to eclipse-resistance research recommendations.