Erlay is a proposed way to relay unconfirmed transactions across Bitcoin’s P2P network. It combines ordinary announcements with set reconciliation, which identifies differences between sets of transaction identifiers. It saves bandwidth without changing consensus or the need to validate every transaction received.
In ordinary relay, connected nodes send INV messages containing 32-byte transaction identifiers. A neighbor often already knows the transaction. More connections increase this overhead, even though diverse connections help protect nodes from isolation and the network from partitioning. [1]
Erlay retains rapid announcements on a small subset of connections. On the others, pairs of nodes periodically reconcile sets of transactions they have yet to announce. Instead of sending complete lists, they can discover the difference from a compact mathematical summary called a sketch. BIP 330 specifies the P2P extension needed for this. [1]
Each connection has its own set, and each round uses a fixed snapshot of that set. Both sides contribute a salt, an auxiliary input for deriving short 32-bit identifiers from wtxid. PinSketch lets them reconcile sets of these identifiers. The messages sendtxrcncl, reqrecon, sketch, reqsketchext and reconcildiff negotiate support, exchange summaries and identify missing announcements. [1]
After finding a difference, a node still requests the complete transaction and validates it under its own rules. Salt limits the ability to precompute short-ID collisions; it is neither a password nor transaction encryption. If the sketch is too small, an extension can be requested. If reconciliation fails, the protocol falls back to ordinary announcements. Implementations must bound computation and memory so a peer cannot easily exhaust them. [1]
When checked in October 2026, BIP 330 had Draft status and described a revised procedure compared with the original paper. Bitcoin Core discussion #34542 was reassessing bandwidth savings, latency and code complexity. This alone does not establish that a particular Bitcoin Core release uses Erlay. Its release notes, implementation and negotiated support between both nodes are what matter. [4]
Under its experimental conditions, the 2019 paper reports roughly 40% less total bandwidth and 84% less bandwidth for transaction announcements. These are simulation and prototype results, not a promise for every present-day network. Waiting for another round can increase latency; a node that receives transactions but refuses to relay them can delay propagation further. Savings and speed need to be measured together. [2]
Erlay reduces repeated announcements of unconfirmed transactions. Compact Blocks instead reduces the data needed to reconstruct a new block from transactions the node mostly already knows. The mechanisms complement each other, but neither by itself conceals a node’s network identity. Each needs its own failure handling and protection against resource exhaustion. [3]
Start with the BIP 330 version and the code the node actually runs. Check support negotiation, short-ID derivation and salt, round timing, sketch limits and reqsketchext behavior. Also check fallback to ordinary announcements and subsequent validation of the complete transaction. The name Erlay alone says nothing about the savings or latency achieved. [1]
For the clearest picture, read this entry together with Mempool, Bitcoin Core, Compact Blocks, Full Node, Sybil Attack, Eclipse Attack. The reverse links also lead from Block Propagation.
01Does BIP 330 mean my Bitcoin Core already uses Erlay?+
No. The specification alone gives no such guarantee. Check the particular release, its implementation and whether both nodes negotiated support. Experimental code or a research paper is not the same as a feature enabled on your node.
02Does Erlay replace transaction validation?+
No. It helps discover which announcements the other side is missing. The node still requests the full transaction and applies its own rules to decide whether to accept it into its mempool and relay it.