Compact Block Relay: How BIP 152 Speeds Up Bitcoin Block Propagation

Every ten minutes, a Bitcoin miner assembles a block containing thousands of transactions and broadcasts it to the network. Before compact block relay, that meant transmitting the entire block to every connected peer, even though those peers already had most of the transactions sitting in their mempools. For a 1 MB block, this redundancy added up to gigabytes of wasted bandwidth across the network per day.

BIP 152, authored by Matt Corallo and shipped in Bitcoin Core 0.13.0 in August 2016, introduced compact block relay: a protocol optimization that replaces full block transmission with a compact sketch containing short transaction IDs. A typical 1 MB block shrinks to roughly 15 KB on the wire, a 97-98% bandwidth reduction that fundamentally changed how quickly blocks propagate across the peer-to-peer network.

Why Block Propagation Speed Matters

Block propagation latency is not just a performance metric: it directly affects Bitcoin's security and fairness. When a miner discovers a valid block, every millisecond of delay before that block reaches other miners creates a window for competing blocks, producing stale (orphan) blocks that waste proof-of-work and reduce network efficiency.

Research by Decker and Wattenhofer (2013) measured median block propagation times of 6.5 seconds, with a mean of 12.6 seconds and a 95th percentile reaching approximately 40 seconds. During high-congestion periods, full network saturation could take 30 to 60 seconds. These delays created measurable advantages for large, well-connected mining pools, which could begin mining the next block immediately on their own discovery while smaller miners were still downloading the previous one.

The centralization risk: Slow block propagation creates a structural advantage for large miners. A pool controlling 30% of hashrate effectively has zero propagation delay for 30% of blocks it discovers, while solo miners always face the full delay. This asymmetry makes selfish mining strategies more profitable and pushes the network toward mining centralization.

How Compact Block Relay Works

The core insight behind compact blocks is simple: if a node already has most of a block's transactions in its mempool, the block announcement only needs to identify which transactions are included and in what order. Rather than sending full transaction data, the announcing node sends short 6-byte identifiers that the receiving node uses to reconstruct the block from its own mempool.

Short Transaction IDs

Each transaction in a compact block is represented by a 6-byte (48-bit) short ID computed using SipHash-2-4, a fast keyed hash function. The computation proceeds in three steps:

1. Compute SHA-256 of the block header concatenated with a random nonce chosen by the sender. The first 16 bytes of the result become two 64-bit SipHash keys (k0 and k1).
2. For each transaction, compute SipHash-2-4 of its transaction ID (or witness transaction ID in version 2) using those keys.
3. Truncate the 8-byte SipHash output to 6 bytes by dropping the two most significant bytes.

This design is deliberate. Deriving keys from the block header prevents attackers from predicting short IDs before a block is mined. The per-connection nonce ensures that random hash collisions on one connection do not affect others. For a block with 10,000 transactions matched against a mempool of 100,000 entries, the probability of a collision-induced reconstruction failure is approximately one in 281,474 blocks.

The cmpctblock Message

When a node sends a compact block, the message contains four components:

• The 80-byte block header
• An 8-byte nonce for SipHash key derivation
• A list of 6-byte short IDs for each transaction in the block (minus prefilled transactions)
• Prefilled transactions: the coinbase transaction is always included because it cannot exist in any node's mempool, and additional transactions predicted to be missing may also be included (up to 10 KB recommended)

Block Reconstruction

Upon receiving a compact block, the node attempts to reconstruct the full block by matching short IDs against transactions in its mempool. If every transaction is found, the block is fully reconstructed and validated without any additional network round-trips.

When transactions are missing (the node never received them, or they were evicted from its mempool), the node sends a getblocktxn message requesting the specific missing transactions by index. The sender responds with a blocktxn message containing only the requested full transactions. This fallback adds one network round-trip but still transfers far less data than a full block download.

High-Bandwidth vs Low-Bandwidth Mode

BIP 152 defines two operating modes that nodes negotiate using the sendcmpct message. Each serves a different purpose in the network's propagation topology.

In high-bandwidth mode, a peer sends compact blocks immediately upon receiving a new block, before performing full validation (only basic header and proof-of-work checks are required). This aggressive approach minimizes latency at the cost of occasionally sending invalid blocks. Nodes typically enable high-bandwidth mode with only their three most performant peers to limit bandwidth waste.

Low-bandwidth mode is more conservative: the sender first validates the block fully, then announces it via standard inv or headers messages. The receiver explicitly requests the compact block. This adds latency but eliminates the possibility of relaying invalid data, making it appropriate for the majority of peer connections.

Why both modes exist: High-bandwidth mode optimizes for the critical path: getting new blocks to miners as fast as possible. Low-bandwidth mode conserves resources for the bulk of a node's connections. Together, they create a propagation topology where a small number of fast paths carry blocks at near-optimal speed while the rest of the network follows without wasting bandwidth on duplicate transmissions.

Measuring the Improvement

The impact of compact block relay on propagation latency has been significant. Before BIP 152, Matt Corallo's Fast Relay Network (later replaced by FIBRE) demonstrated that dedicated relay infrastructure could bring propagation down from 30-60 seconds to 10-20 seconds. Compact blocks brought similar improvements to the general peer-to-peer network without requiring specialized infrastructure.

FIBRE (Fast Internet Bitcoin Relay Engine), also built by Matt Corallo, combined compact blocks with UDP-based forward error correction to achieve sub-second global propagation: blocks reaching the opposite side of the planet in under one second. While FIBRE served as specialized relay infrastructure, compact blocks delivered the foundational bandwidth reduction that made such speeds possible on the open peer-to-peer network.

Version 1 vs Version 2

BIP 152 originally defined two protocol versions. Version 1 shipped with Bitcoin Core 0.13.0 and used transaction IDs (txids) for short ID computation. Version 2 arrived with SegWit support in Bitcoin Core 0.13.1 and switched to witness transaction IDs (wtxids), which include the serialized witness data in the hash computation as specified by BIP 141.

Version 1 has since been removed from Bitcoin Core (PR #20799). Since every Bitcoin Core release since 0.13.1 supports SegWit, and the last non-witness block was mined years ago, only version 2 is negotiated in modern nodes. Version 2 compact blocks can still relay blocks without witness data, making version 1 entirely redundant.

Compact Blocks and Mining Centralization

The relationship between block propagation speed and mining centralization is well-documented. When propagation is slow, larger mining operations gain a compounding advantage: they can begin mining the next block immediately upon their own discovery (zero self-propagation delay), while smaller miners must wait to receive and validate the block. This asymmetry manifests in higher orphan rates for smaller miners, reducing their effective revenue per unit of hashrate.

Compact blocks substantially reduce this advantage by making propagation time a function of network latency (speed of light) rather than bandwidth. When the data transmitted drops from megabytes to kilobytes, even a home-connected full node can receive new blocks nearly as quickly as a datacenter-hosted mining operation. The stale block rate dropping from 1-2% to below 0.1% means solo miners and small pools lose far fewer blocks to propagation disadvantage.

This also raises the bar for selfish mining attacks, where a miner withholds discovered blocks to gain a head start on the next block. Faster baseline propagation narrows the timing window that selfish miners exploit, requiring a higher hashrate threshold for the attack to be profitable.

When Reconstruction Fails: Mempool Divergence

Compact block relay works best when all nodes maintain similar mempools. When mempools diverge, reconstruction failure rates increase, and nodes must fall back to requesting missing transactions via getblocktxn/blocktxn round-trips. Several factors cause mempool divergence:

• Different mempool policies across nodes (minimum relay feerate, replace-by-fee settings, transaction size limits)
• Transactions that arrive at nodes at different times due to network topology
• Miners including transactions that many nodes have not yet seen or have already evicted

This became a practical issue in 2025 when miners began including sub-1-sat/vbyte transactions that most nodes' mempools rejected due to higher default minimum relay feerates. By late July 2025, 85% of hashrate had adopted lower minimum feerates, causing widespread compact block reconstruction failures. Bitcoin Core 29.1 responded by lowering the default minimum relay feerate to 0.1 sat/vbyte, improving mempool convergence and reconstruction success rates.

Mitigation Strategies

Several approaches address reconstruction failures:

• Prefilling: senders can include up to 10 KB of transactions predicted to be missing from the receiver's mempool alongside the compact block
• Block template sharing: a proposal from August 2025 (BIPs #1937) would allow nodes to periodically exchange block templates in compact block format, pre-caching transactions that might otherwise be missing
• Weak blocks: caching transactions from blocks with insufficient proof-of-work but valid structure, using them as a source for compact block reconstruction
• Full RBF (mempoolfullrbf): enabling full replace-by-fee has been shown to improve reconstruction efficiency by keeping mempools more consistent with miner block templates

How Erlay Complements Compact Blocks

While compact blocks optimize block relay bandwidth, Erlay (BIP 330) targets the other major bandwidth consumer: transaction relay. Together, they address the two dominant sources of node bandwidth usage.

Currently, every unconfirmed transaction is announced via INV messages to every connected peer, creating enormous redundancy. Erlay replaces this flood-based approach with set reconciliation using Minisketch, a library implementing BCH-code-based set reconciliation. Rather than announcing every transaction to every peer, nodes limit direct flooding to a small subset of outbound connections and periodically reconcile transaction sets with remaining peers by exchanging compact set difference sketches.

Erlay is estimated to reduce transaction relay bandwidth by approximately 40%, saving some nodes up to 100 MB per day. Critically, it also enables nodes to maintain more peer connections without proportional bandwidth increases, improving resistance to eclipse attacks and network partitions. More connections also improve mempool consistency across the network, which directly benefits compact block reconstruction rates.

Erlay remains under active development. The sendtxrcncl negotiation message was merged into Bitcoin Core in 2022, and encoding support has been added to Rust Bitcoin implementations. Deployment is expected in a future Bitcoin Core release. For a deeper look, see our coverage of the Erlay transaction relay protocol.

Security Considerations

Compact block relay introduces its own attack surface. In October 2024, Bitcoin Core disclosed CVE-2024-35202, a remote crash vulnerability in compact block reconstruction (CVSS 7.5). The bug allowed an attacker to send a crafted compact block that triggered a short-ID collision, leaving the reconstruction state machine in an inconsistent state. A subsequent blocktxn message would then call the FillBlock function a second time, violating an internal invariant and crashing the node. The vulnerability affected all Bitcoin Core versions before 25.0 and was fixed in PR #26898.

This incident highlights an important principle: protocol optimizations that add complexity to message handling create new surface area for implementation bugs, even when the underlying cryptographic design is sound. The Bitcoin Core project has since added stricter validation for sendcmpct announcement fields and improved peer negotiation requirements.

Compact Blocks in Context: Bitcoin's Relay Stack

Compact block relay is one piece of a broader set of relay optimizations that strengthen Bitcoin's consensus layer. Understanding how these components fit together clarifies why each matters:

• Compact blocks (BIP 152) reduce block relay bandwidth by 97-98%
• Erlay (BIP 330) reduces transaction relay bandwidth by approximately 40%
• BIP 324 (v2 transport protocol) encrypts all peer-to-peer traffic, preventing ISP-level block withholding or transaction censorship
• Headers-first sync allows nodes to verify the chain of headers before downloading full blocks, improving initial block download efficiency
• Compact block filters (BIP 157/158) enable lightweight clients to check for relevant transactions without downloading full blocks

Each optimization targets a different bottleneck, but they share a common goal: making it cheaper and faster to run a fully validating node. The easier it is to validate, the more participants can independently verify the blockchain, and the more decentralized and secure the network becomes.

Why This Matters for Layer 2 Protocols

Layer 2 systems like the Lightning Network and Spark inherit their security from Bitcoin's base layer. The strength of that security depends on how reliably and quickly the network reaches consensus on new blocks. Slow propagation increases the risk of chain reorganizations, which can disrupt the settlement guarantees that off-chain protocols rely on.

For Spark specifically, statechain transfers derive their finality from the assumption that the underlying Bitcoin UTXOs remain confirmed and unspent. A network with fast, reliable block propagation minimizes the window for reorgs and double-spend attempts, strengthening the settlement assurances that Layer 2 users depend on. Protocol-level improvements like compact blocks and Stratum V2 contribute to a more robust base layer that every Layer 2 benefits from.

Developers building on Bitcoin's Layer 2 stack can explore the Spark SDK documentation to understand how statechain transfers work on top of these base-layer guarantees. For a broader comparison of how different Layer 2 approaches handle settlement, see our Bitcoin Layer 2 comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.