Compact Blocks

What Are Compact Blocks?

Compact blocks are a Bitcoin peer-to-peer protocol optimization, specified in BIP 152, that dramatically reduces the bandwidth required to propagate new blocks across the network. The core insight is simple: by the time a miner finds a block, most nodes on the network already have the vast majority of its transactions sitting in their mempool. Retransmitting those transactions inside the block is redundant. Compact blocks eliminate that redundancy by sending only short transaction identifiers, allowing the receiving node to reconstruct the full block locally.

Authored by Matt Corallo and first deployed in Bitcoin Core v0.13.0 (August 2016), compact blocks addressed one of Bitcoin's most pressing scaling challenges: slow block propagation. Before BIP 152, relaying a full block could take 30 to 60 seconds across the global network. This delay created orphan races, wasted miner resources, and gave large mining operations with optimized infrastructure a structural advantage over smaller participants.

How It Works

Compact block relay introduces four new message types to the Bitcoin P2P protocol: sendcmpct, cmpctblock, getblocktxn, and blocktxn. Together they replace the traditional full-block download with a lightweight sketch-and-reconstruct flow.

1. Two peers exchange sendcmpct messages during connection setup, negotiating whether to use compact relay and which mode (high-bandwidth or low-bandwidth) to prefer
2. When a new block arrives, the sender transmits a cmpctblock message containing the 80-byte block header, a random nonce, a list of 6-byte short transaction IDs, and a small set of prefilled transactions (always including the coinbase transaction)
3. The receiver matches short IDs against transactions in its mempool to reconstruct the block locally
4. If any transactions are missing, the receiver sends a getblocktxn request with the indexes of the missing transactions
5. The original sender responds with a blocktxn message containing the full missing transactions
6. The receiver verifies the reconstructed block against the Merkle root in the header and, if valid, adds it to the chain

In practice, over 90% of blocks propagate in a single round trip with no missing transactions when the sender prefills up to 6 predicted-missing transactions beyond the coinbase. A typical 1 MB block compresses to roughly 20 to 30 KB of compact sketch data.

Short Transaction IDs

The 6-byte short IDs are the key space-saving mechanism. Each ID is computed using SipHash-2-4, a fast, collision-resistant keyed hash function:

// Short ID computation (per BIP 152)
// 1. Compute SHA-256 of block header + nonce
key = SHA256(block_header || nonce)

// 2. Extract two 64-bit SipHash keys from the hash
k0 = key[0..8]   // first 8 bytes, little-endian
k1 = key[8..16]  // next 8 bytes, little-endian

// 3. For each transaction, compute SipHash and truncate
short_id = SipHash-2-4(k0, k1, wtxid) & 0xFFFFFFFFFFFF  // 6 bytes

The block header is part of the key derivation, so short IDs cannot be predicted before the block is mined. A per-connection nonce ensures that each peer relationship uses independent short IDs, preventing even the block creator from engineering collisions across the network. With 48-bit IDs, the probability of a collision in a block with 10,000 transactions and a mempool of 100,000 transactions is approximately 1 in 281,474 blocks.

High-Bandwidth vs. Low-Bandwidth Mode

BIP 152 defines two relay modes that let nodes balance latency against bandwidth consumption:

Bitcoin Core nodes designate up to 3 peers for high-bandwidth mode, prioritizing low latency for the fastest block awareness. All other peers use low-bandwidth mode to conserve resources.

Version 1 and Version 2

BIP 152 specifies two protocol versions. Version 1 used the txid for short ID computation. Version 2, introduced alongside SegWit (BIP 141), switched to using the wtxid (witness transaction ID) so that witness data is included in the compact block flow. Since SegWit activation in August 2017, version 1 has been obsolete. Bitcoin Core v22.0 (2021) removed version 1 support entirely, and all current nodes use version 2 exclusively.

Why It Matters

Block propagation speed has direct consequences for network security and decentralization. When blocks take a long time to reach all nodes, multiple miners may find valid blocks at similar heights, creating orphan races. The miner with faster propagation wins more often, creating an economic incentive to centralize around large pools with optimized infrastructure.

Before compact blocks, stale block rates were estimated at 1 to 2% of all blocks. With compact blocks reducing propagation to under 5 seconds across the global network, stale rates have dropped to well below 0.1%. This improvement benefits smaller miners and solo operators disproportionately: their blocks now propagate nearly as fast as those from large pools, making the network more resilient against mining centralization.

For layer-2 protocols like the Lightning Network and Spark, fast and reliable block propagation is foundational. These systems depend on timely on-chain confirmations for channel opens, closes, and dispute resolution. Compact blocks help ensure that the base layer remains responsive enough to support the growing ecosystem built on top of it.

Use Cases

Mining Operations

Miners are the primary beneficiaries of compact blocks. Every second of propagation delay increases the risk that a competing block at the same height arrives first, rendering their work worthless. By cutting propagation from tens of seconds to a few seconds, compact blocks reduce orphan risk and make mining economics more predictable.

Bandwidth-Constrained Nodes

Full nodes running on residential connections, VPSes with transfer caps, or in regions with limited bandwidth benefit substantially from the 97% reduction in block relay data. Running a full node becomes more accessible, strengthening network decentralization.

Network Resilience

Compact blocks work alongside other propagation improvements to form a layered defense against network partitions and eclipse attacks. The FIBRE (Fast Internet Bitcoin Relay Engine) protocol, also created by Matt Corallo, built on top of compact blocks by adding UDP transport and forward error correction to achieve near-speed-of-light relay between mining pools.

Transaction Relay Synergy

Compact blocks are complementary to Erlay (BIP 330), a proposed improvement to transaction relay that uses set reconciliation to reduce bandwidth by approximately 40%. While compact blocks optimize block propagation, they depend on mempool consistency between peers. Erlay helps maintain that consistency more efficiently, enabling nodes to sustain more peer connections without proportional bandwidth increases.

Risks and Considerations

Mempool Divergence

Compact blocks work best when peers have similar mempool contents. During periods of extreme congestion, non-standard transaction policies, or mempool eviction, nodes may hold significantly different transaction sets. When mempools diverge, compact block reconstruction fails more frequently, requiring additional round trips to fetch missing transactions and partially negating the latency benefits. In severe cases, reconstruction success rates can drop below 50%.

Short ID Collisions

Although rare (approximately 1 in 281,474 blocks), short ID collisions can cause reconstruction failures. When a collision is detected via Merkle root mismatch, the node falls back to requesting the full block. This is a graceful degradation rather than a security risk, but it does add latency in those cases.

Historical Vulnerability: CVE-2024-35202

In 2022, researcher Niklas Gogge discovered a vulnerability in compact block reconstruction logic. When a short ID collision triggered a reconstruction failure and a second blocktxn message arrived for the same block, the node could crash due to a violated assertion. An attacker could trigger this remotely by crafting specific block responses. The fix, merged in January 2023, was released in Bitcoin Core v25.0 and publicly disclosed in October 2024. This incident underscored the importance of defensive coding in protocol-level optimizations.

Does Not Replace Full Validation

Compact blocks accelerate block delivery, not block validation. Every node still fully validates each reconstructed block against all consensus rules. In high-bandwidth mode, a compact block is forwarded before full validation, meaning a node may occasionally relay invalid compact blocks. This is harmless: receiving nodes validate independently and discard invalid blocks. The protocol explicitly stopped penalizing peers for sending invalid compact blocks as of protocol version 70015.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.