Compact blocks - Revision history

NotATether: Add Relay problem, Protocol, and Deployment sections

2026-09-13T07:34:45Z

Add Relay problem, Protocol, and Deployment sections

← Older revision		Revision as of 07:34, 13 September 2026
Line 1:		Line 1:
	'''Compact blocks''' are a peer-to-peer protocol for announcing and transferring blocks using short transaction identifiers instead of full transaction data. Peers reconstruct a block from their [[Mempool\|mempools]] and request only the missing transactions. The protocol is specified in BIP152, authored by Matt Corallo. Version 1 uses txids. Version 2 uses wtxids and includes witness data for [[Segregated Witness]].		'''Compact blocks''' are a peer-to-peer protocol for announcing and transferring blocks using short transaction identifiers instead of full transaction data. Peers reconstruct a block from their [[Mempool\|mempools]] and request only the missing transactions. The protocol is specified in BIP152, authored by Matt Corallo. Version 1 uses txids. Version 2 uses wtxids and includes witness data for [[Segregated Witness]].

			== Relay problem ==

	Before compact blocks, a newly mined block was relayed as a full <code>block</code> message containing every transaction. Most of those transactions were already in receiving nodes' mempools, so the extra bandwidth was wasted. Outbound spikes caused bufferbloat on residential links and delayed further relay. Compact block relay aims to cut that bandwidth. Lower latency is a side effect, not the primary goal. Later work such as FIBRE and erasure-coded relay targeted latency more directly.		Before compact blocks, a newly mined block was relayed as a full <code>block</code> message containing every transaction. Most of those transactions were already in receiving nodes' mempools, so the extra bandwidth was wasted. Outbound spikes caused bufferbloat on residential links and delayed further relay. Compact block relay aims to cut that bandwidth. Lower latency is a side effect, not the primary goal. Later work such as FIBRE and erasure-coded relay targeted latency more directly.

			== Protocol ==

	Peers negotiate with a <code>sendcmpct</code> message that carries a boolean and a version. The boolean selects high-bandwidth or low-bandwidth mode. High-bandwidth mode, recommended toward at most a few peers, causes the sender to push a <code>cmpctblock</code> as soon as it has a valid header and a commitment to the transaction list, possibly before full validation. Low-bandwidth mode announces with headers or inv, after which the receiver may <code>getdata</code> with type MSG_CMPCT_BLOCK.		Peers negotiate with a <code>sendcmpct</code> message that carries a boolean and a version. The boolean selects high-bandwidth or low-bandwidth mode. High-bandwidth mode, recommended toward at most a few peers, causes the sender to push a <code>cmpctblock</code> as soon as it has a valid header and a commitment to the transaction list, possibly before full validation. Low-bandwidth mode announces with headers or inv, after which the receiver may <code>getdata</code> with type MSG_CMPCT_BLOCK.
Line 13:		Line 17:
	Mempool synchronization quality dominates reconstruction success. Peers that recently shared transactions through ordinary inv relay reconstruct most blocks with few or no <code>getblocktxn</code> round trips. After a long partition or during a large unexpected block, missing-transaction requests rise and latency approaches that of full block relay.		Mempool synchronization quality dominates reconstruction success. Peers that recently shared transactions through ordinary inv relay reconstruct most blocks with few or no <code>getblocktxn</code> round trips. After a long partition or during a large unexpected block, missing-transaction requests rise and latency approaches that of full block relay.

	Version 2 short IDs over wtxid avoid ambiguity when the same txid could pair with different witnesses. SegWit-aware nodes prefer version 2 once negotiated. Compact block relay is orthogonal to [[Erlay]], which targets unconfirmed transaction announcements rather than block transfer. Operators still use compact blocks as the default low-bandwidth path for new blocks among fully validating peers.		== Deployment ==

			Version 2 short IDs over wtxid avoid ambiguity when the same txid could pair with different witnesses. SegWit-aware nodes prefer version 2 once negotiated. Compact block relay is orthogonal to [[Erlay]], which targets unconfirmed transaction announcements rather than block transfer. Operators still use compact blocks as the default low-bandwidth path for new blocks among fully validating peers. High-bandwidth mode sends the compact block to selected peers without waiting for an <code>inv</code> round trip, which cuts latency when the peer is expected to reconstruct successfully.

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

NotATether: Expand See also links

2026-09-13T07:20:18Z

Expand See also links

← Older revision		Revision as of 07:20, 13 September 2026
Line 18:		Line 18:
	* [[Segregated Witness]]		* [[Segregated Witness]]
	* [[Mempool]]		* [[Mempool]]
			* [[Erlay]]
	* [[Bitcoin Core]]		* [[Bitcoin Core]]
	* [[Full node]]		* [[Full node]]

NotATether: Add wtxid version and Erlay contrast

2026-09-13T07:20:17Z

Add wtxid version and Erlay contrast

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

	Mempool synchronization quality dominates reconstruction success. Peers that recently shared transactions through ordinary inv relay reconstruct most blocks with few or no <code>getblocktxn</code> round trips. After a long partition or during a large unexpected block, missing-transaction requests rise and latency approaches that of full block relay.		Mempool synchronization quality dominates reconstruction success. Peers that recently shared transactions through ordinary inv relay reconstruct most blocks with few or no <code>getblocktxn</code> round trips. After a long partition or during a large unexpected block, missing-transaction requests rise and latency approaches that of full block relay.

			Version 2 short IDs over wtxid avoid ambiguity when the same txid could pair with different witnesses. SegWit-aware nodes prefer version 2 once negotiated. Compact block relay is orthogonal to [[Erlay]], which targets unconfirmed transaction announcements rather than block transfer. Operators still use compact blocks as the default low-bandwidth path for new blocks among fully validating peers.

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

NotATether: Add mempool sync and reconstruction quality

2026-09-13T07:20:15Z

Add mempool sync and reconstruction quality

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

	[[Bitcoin Core]] implemented version 1 in pull request 8068 and version 2 (witness) in 8393. Compact block relay is the default block-announcement path among Core peers. Other [[Full node\|full node]] implementations (btcd, libbitcoin, knots) implement BIP152 with varying completeness. SPV clients generally do not use high-bandwidth mode, because they would be accepting unvalidated transaction lists from a peer. Compact block filters (BIP158) are a separate client-side filter design and are not the same as compact block relay.		[[Bitcoin Core]] implemented version 1 in pull request 8068 and version 2 (witness) in 8393. Compact block relay is the default block-announcement path among Core peers. Other [[Full node\|full node]] implementations (btcd, libbitcoin, knots) implement BIP152 with varying completeness. SPV clients generally do not use high-bandwidth mode, because they would be accepting unvalidated transaction lists from a peer. Compact block filters (BIP158) are a separate client-side filter design and are not the same as compact block relay.

			Mempool synchronization quality dominates reconstruction success. Peers that recently shared transactions through ordinary inv relay reconstruct most blocks with few or no <code>getblocktxn</code> round trips. After a long partition or during a large unexpected block, missing-transaction requests rise and latency approaches that of full block relay.

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

NotATether: Create Compact blocks stub: BIP152 short-ID relay; v1 txid / v2 wtxid; high- vs low-bandwidth; link SegWit/Mempool/Bitcoin Core/Full node

2026-09-12T20:30:23Z

Create Compact blocks stub: BIP152 short-ID relay; v1 txid / v2 wtxid; high- vs low-bandwidth; link SegWit/Mempool/Bitcoin Core/Full node

New page

'''Compact blocks''' are a peer-to-peer protocol for announcing and transferring blocks using short transaction identifiers instead of full transaction data. Peers reconstruct a block from their [[Mempool|mempools]] and request only the missing transactions. The protocol is specified in BIP152, authored by Matt Corallo. Version 1 uses txids. Version 2 uses wtxids and includes witness data for [[Segregated Witness]].

Before compact blocks, a newly mined block was relayed as a full <code>block</code> message containing every transaction. Most of those transactions were already in receiving nodes' mempools, so the extra bandwidth was wasted. Outbound spikes caused bufferbloat on residential links and delayed further relay. Compact block relay aims to cut that bandwidth. Lower latency is a side effect, not the primary goal. Later work such as FIBRE and erasure-coded relay targeted latency more directly.

Peers negotiate with a <code>sendcmpct</code> message that carries a boolean and a version. The boolean selects high-bandwidth or low-bandwidth mode. High-bandwidth mode, recommended toward at most a few peers, causes the sender to push a <code>cmpctblock</code> as soon as it has a valid header and a commitment to the transaction list, possibly before full validation. Low-bandwidth mode announces with headers or inv, after which the receiver may <code>getdata</code> with type MSG_CMPCT_BLOCK.

A <code>cmpctblock</code> contains the 80-byte header, a nonce, 6-byte short IDs for most transactions, and a few prefilled transactions (always enough to include the coinbase, and typically limited to about 10 kB). Short IDs are SipHash-2-4 of the txid (version 1) or wtxid (version 2), keyed by SHA256(header || nonce). Using the block hash in the key prevents an attacker from grinding collisions that affect every link. The receiver matches short IDs to mempool transactions. For unmatched positions it sends <code>getblocktxn</code> with differentially encoded indexes. The sender replies with <code>blocktxn</code>. Random short-ID collisions are expected to be rare and are resolved by falling back to a full block. Nodes must not punish peers for collisions.

High-bandwidth compact blocks may be announced before full validation. Protocol version 70015 and higher signal that a node will not ban a peer for an invalid compact-block announcement that still has a valid header. Compact-block senders still must not announce headers that fail proof of work or prev-hash checks.

[[Bitcoin Core]] implemented version 1 in pull request 8068 and version 2 (witness) in 8393. Compact block relay is the default block-announcement path among Core peers. Other [[Full node|full node]] implementations (btcd, libbitcoin, knots) implement BIP152 with varying completeness. SPV clients generally do not use high-bandwidth mode, because they would be accepting unvalidated transaction lists from a peer. Compact block filters (BIP158) are a separate client-side filter design and are not the same as compact block relay.

== See also ==
* [[Segregated Witness]]
* [[Mempool]]
* [[Bitcoin Core]]
* [[Full node]]

== External links ==
* [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152: Compact Block Relay]
* [https://bitcoinops.org/en/topics/compact-block-relay/ Bitcoin Optech: Compact block relay]
* [https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/ Compact blocks FAQ]
* [https://github.com/bitcoin/bitcoin/pull/8068 Bitcoin Core PR 8068]

[[Category:Technical]]