Compact Block Relay (BIP152)

Compact Block Relay, specified in BIP152, reduces the bandwidth and latency of propagating a newly mined block across the Bitcoin network. Instead of resending every transaction in full, a node forwards the 80-byte block header plus a list of 6-byte short transaction identifiers. Because well-connected peers typically already hold the same unconfirmed transactions in their mempools, the receiver can reconstruct the block locally and request only the handful of transactions it is missing — usually turning a block-sized download into a few kilobytes.

Why block propagation speed matters

Every second a new block spends in transit is a second during which miners elsewhere are still hashing on the old tip. Slow propagation raises the stale-block rate, and it does so unevenly: large, well-connected operations hear about blocks first, while smaller and more remote miners waste proportionally more work. Fast, cheap relay therefore is not just a bandwidth nicety — it is a decentralization property. The easier it is for a modest node on a residential connection to receive and validate new blocks quickly, the less advantage raw network position confers, and the more viable it is to run full infrastructure from anywhere.

High-bandwidth and low-bandwidth modes

Peers negotiate behavior with the sendcmpct message. In high-bandwidth mode, a peer pushes a cmpctblock immediately upon validating a new block's header — before fully validating the block — achieving roughly half a round trip of best-case latency; a node typically grants this mode to a few of its fastest-relaying peers. In low-bandwidth mode, the peer announces the block first and serves the compact form only on request, trading a little latency for less redundant traffic. Either way, the receiver rebuilds the block from its mempool, fetches any transactions it lacks with getblocktxn, receives them via blocktxn, and falls back to requesting the full block if reconstruction fails.

Short IDs and collision resistance

The 6-byte (48-bit) short identifiers are computed with SipHash-2-4, keyed from the block header and a per-block nonce chosen by the sender. Keying matters: without it, an attacker could precompute distinct transactions whose identifiers collide and broadcast them to jam reconstruction network-wide. Because the key changes with every block and every sender, collisions become rare accidents (handled by falling back to fuller requests) rather than an attack surface. Version 2 of the scheme uses witness transaction IDs (wtxids) so SegWit transaction data is covered by the identifier. It is worth noting what compact blocks are not: they are a bandwidth and latency optimization, not a change to validation — every node still fully validates every transaction in the reconstructed block against its own rules.

Relationship to mining and other relay work

For miners, faster relay directly shrinks orphan risk, which historically pushed operators toward large pools and private relay networks; BIP152 narrowed that gap using the public peer-to-peer network itself. The design also rewards keeping a healthy mempool, since reconstruction succeeds when you already know the transactions — one more reason a mining operation benefits from running a real node rather than trusting someone else's. Compact blocks complement, but differ from, transaction-announcement efficiency work such as Erlay (BIP330), which optimizes the steady gossip of individual transactions rather than block delivery. For how a node first establishes the chain it is extending, see headers-first sync; for the economics of why every stale block matters to a miner, start at block reward.

None of this requires configuration on your part — compact block relay has been standard behavior in Bitcoin Core for years — but it does reward one habit: keep your node's mempool policy near defaults if you want fast reconstruction, since a heavily filtered mempool means more missing-transaction round trips when blocks arrive.

Watch real propagation context in the live network vitals.