Erlay - Revision history

NotATether: Add Flooding cost, Set reconciliation, and Status sections

2026-09-13T07:35:16Z

Add Flooding cost, Set reconciliation, and Status sections

← Older revision		Revision as of 07:35, 13 September 2026
Line 1:		Line 1:
	'''Erlay''' is a proposed Bitcoin transaction-relay protocol, specified in BIP 330, that replaces most flooding of <code>inv</code> 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.		'''Erlay''' is a proposed Bitcoin transaction-relay protocol, specified in BIP 330, that replaces most flooding of <code>inv</code> 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 <code>inv</code> to most of its peers, who request the transaction with <code>getdata</code> 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\|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.		On the current gossip network, a node that accepts a new transaction sends an <code>inv</code> to most of its peers, who request the transaction with <code>getdata</code> 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\|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 <code>sendtxrcncl</code> 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 <code>getdata</code> and enter the [[Mempool\|mempool]] like any other relayed transaction.		BIP 330 introduces a reconciliation protocol. After the usual version handshake, peers that support Erlay send a <code>sendtxrcncl</code> 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 <code>getdata</code> and enter the [[Mempool\|mempool]] like any other relayed transaction.
Line 11:		Line 15:
	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 <code>sendtxrcncl</code> let peers agree on salt, quantum, and related timing knobs before reconciliation begins.		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 <code>sendtxrcncl</code> let peers agree on salt, quantum, and related timing knobs before reconciliation begins.

	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.		== 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.

	== See also ==		== See also ==

NotATether: Remove redlink See also target

2026-09-13T07:21:22Z

Remove redlink See also target

← Older revision		Revision as of 07:21, 13 September 2026
Line 18:		Line 18:
	* [[Compact blocks]]		* [[Compact blocks]]
	* [[Bitcoin Core]]		* [[Bitcoin Core]]
	* [[Eclipse attack]]

	== External links ==		== External links ==

NotATether: Expand See also links

2026-09-13T07:20:53Z

Expand See also links

← Older revision		Revision as of 07:20, 13 September 2026
Line 18:		Line 18:
	* [[Compact blocks]]		* [[Compact blocks]]
	* [[Bitcoin Core]]		* [[Bitcoin Core]]
			* [[Eclipse attack]]

	== External links ==		== External links ==

NotATether: Add deployment status and fanout goals

2026-09-13T07:20:51Z

Add deployment status and fanout goals

← Older revision		Revision as of 07:20, 13 September 2026
Line 10:		Line 10:

	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 <code>sendtxrcncl</code> let peers agree on salt, quantum, and related timing knobs before reconciliation begins.		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 <code>sendtxrcncl</code> let peers agree on salt, quantum, and related timing knobs before reconciliation begins.

			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.

	== See also ==		== See also ==

NotATether: Add Minisketch capacity and negotiation

2026-09-13T07:20:49Z

Add Minisketch capacity and negotiation

← Older revision		Revision as of 07:20, 13 September 2026
Line 8:		Line 8:

	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.		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 <code>sendtxrcncl</code> let peers agree on salt, quantum, and related timing knobs before reconciliation begins.

	== See also ==		== See also ==

NotATether: Create Erlay stub: BIP 330 set reconciliation vs inv flooding; Minisketch; not yet in released Bitcoin Core; link Network/Mempool/Compact blocks/Bitcoin Core

2026-09-12T20:51:19Z

Create Erlay stub: BIP 330 set reconciliation vs inv flooding; Minisketch; not yet in released Bitcoin Core; link Network/Mempool/Compact blocks/Bitcoin Core

New page

'''Erlay''' is a proposed Bitcoin transaction-relay protocol, specified in BIP 330, that replaces most flooding of <code>inv</code> 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.

On the current gossip network, a node that accepts a new transaction sends an <code>inv</code> to most of its peers, who request the transaction with <code>getdata</code> 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|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.

BIP 330 introduces a reconciliation protocol. After the usual version handshake, peers that support Erlay send a <code>sendtxrcncl</code> 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 <code>getdata</code> and enter the [[Mempool|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 <code>sendtxrcncl</code> 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.

== See also ==
* [[Network]]
* [[Mempool]]
* [[Compact blocks]]
* [[Bitcoin Core]]

== External links ==
* [https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki BIP 330: Transaction dissemination using reconciliation]
* [https://bitcoinops.org/en/topics/erlay/ Bitcoin Optech: Erlay]
* [https://arxiv.org/pdf/1905.10518.pdf Erlay paper (arXiv)]
* [https://github.com/sipa/minisketch Minisketch]
* [https://github.com/bitcoin/bitcoin/issues/30249 Bitcoin Core Erlay project tracking]

[[Category:Technical]]