Compact Blocks (BIP-152)

Compact Blocks, specified in BIP-152 and merged into Bitcoin Core in 2016, is a peer-to-peer relay optimization that dramatically reduces the bandwidth and latency of propagating new blocks across the network. Faster, leaner block propagation matters directly to miners, because every second a block takes to reach the network raises the risk that another miner's competing block wins the race and the first block is orphaned. It matters just as much to home node runners, because it is the main reason a full node no longer needs to re-download megabytes of data every time a block is found.

How it saves bandwidth

By the time a block is found, most nodes have already received its transactions through normal mempool relay. Rather than resending those full transactions, the sender transmits a compact block: the 80-byte block header plus a short 6-byte identifier for each transaction, computed with the SipHash function and salted per-connection so an attacker cannot precompute collisions. A receiving node matches the short IDs against its own mempool, reconstructs the block locally, and only requests the few transactions it is missing. A multi-megabyte block can shrink to roughly 15 KB on the wire — about a 98% reduction. The sender can also "prefill" transactions it predicts the peer will not have, such as the coinbase, saving a round trip.

High-bandwidth vs low-bandwidth mode

In low-bandwidth mode a node announces a block and waits to be asked for the compact version — minimal bandwidth, one extra round trip. In high-bandwidth mode a peer pushes the compact block unsolicited the moment it sees a valid header, letting well-connected nodes relay most blocks in a single round trip with no follow-up request at all. Nodes typically keep a small set of peers in high-bandwidth mode, chosen from those who have recently delivered blocks fastest. Because compact blocks rely on a shared mempool, they help most near the chain tip, where node mempools are most similar; a node with an empty or heavily filtered mempool falls back to requesting more transactions.

Why miners and node runners should care

For miners, propagation speed is money. A block that spreads slowly is a block at risk of being staled by a competitor, and stale blocks are pure lost revenue — this is one of the quiet forces that historically pushed hashrate toward well-connected pools. Compact blocks, together with dedicated relay networks operated by and for miners, cut typical propagation to a small fraction of a second and levelled that playing field considerably. For a home node — the kind a sovereign Bitcoiner runs behind a residential connection — compact blocks are what make bandwidth budgets manageable: the steady cost is transaction relay, while new blocks arrive nearly free because the node already holds their contents. That efficiency is part of why running a full validating node remains practical on modest hardware and metered connections, which in turn keeps validation decentralized.

Compact blocks arrived after years of iteration on the propagation problem. Early nodes relayed full blocks redundantly to every peer; research relay networks and alternative proposals demonstrated that shipping mostly-redundant transaction data was the bottleneck, and BIP-152 distilled those lessons into the standard peer-to-peer protocol itself. The design also anticipated SegWit: a second version of the scheme identifies transactions by their witness-inclusive IDs so that blocks reconstruct correctly under the upgraded transaction format. Later work attacked the remaining redundancy from the other side — making mempools more similar between peers through smarter transaction relay — because the more alike two mempools are, the more often a compact block reconstructs on the first try with zero follow-up requests. Propagation efficiency turns out to be a system property, not a single trick.

This optimization complements the SegWit-era witness commitment and works alongside the Merkle root structure that lets a reconstructed block be verified against its header. D-Central documents these internals as part of an educational mining reference.