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]]

Compact blocks - Revision history

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