Compact Block

A compact block is a bandwidth-efficient way of relaying a newly mined block, defined in BIP152 and active in Bitcoin Core since 2016. It exploits a simple fact: well-connected nodes already hold most of a block's transactions in their mempools, so retransmitting those transactions in full is pure waste. Instead of resending everything, a peer sends a small sketch that lets the receiver rebuild the block from data it already has on hand.

The motivation is easy to feel if you have ever watched a node on a home connection. When a new block arrives, the naive relay protocol would have your node download every transaction in that block a second time, even though most of them already passed through your mempool minutes earlier. On a constrained residential uplink, that redundant burst is exactly the moment latency spikes and your node briefly falls behind the chain tip. Compact blocks remove almost all of that duplicated transfer, which is why they matter far more to a hobbyist's node than to a datacenter with bandwidth to spare — they are a large part of what keeps running your own full node cheap enough, on ordinary internet, to actually be worth doing rather than delegating.

How the sketch works

The relaying node sends a HeaderAndShortIDs structure containing the full 80-byte block header, a short six-byte non-cryptographic ID for each transaction, and a handful of full transactions it predicts the receiver is missing — the coinbase, at minimum. The short IDs are derived with SipHash keyed per connection, so two peers cannot collude to force ID collisions that would break reconstruction. The receiver matches each short ID against its mempool and slots the corresponding transactions into place. If a few are genuinely absent it requests just those with a getblocktxn follow-up, and the sender replies with only the missing bodies rather than the whole block.

High-bandwidth and low-bandwidth modes

BIP152 defines two relay modes negotiated with a sendcmpct message. In low-bandwidth mode a node waits until it has validated a block, then announces it compactly and lets the peer ask for it. In high-bandwidth mode a trusted peer may push the compact block the instant it arrives, before full validation, shaving critical milliseconds off propagation at the cost of occasionally forwarding a block that turns out invalid. The scheme also has two versions: version 1 keys short IDs on legacy txids, version 2 on witness txids (wtxids) for SegWit compatibility. A node typically maintains high-bandwidth relay with a small number of its fastest peers.

Why it matters for miners

The savings are dramatic. A multi-megabyte block carrying thousands of transactions can be relayed in roughly 15 kilobytes — around a 98% reduction. Smaller messages propagate faster over TCP, and faster propagation directly lowers the orphan rate: the sooner every node sees a new block, the less likely two miners are to build competing chains and waste work. That matters for decentralization, because when propagation is slow, miners have an incentive to cluster around private high-speed relay networks, concentrating exactly the kind of infrastructure that permissionless mining is meant to avoid.

Where it sits in the bigger picture

Compact blocks address block propagation specifically; a separate line of work targets the steady drip of individual transaction relay, where redundant announcements across many peers also waste bandwidth. Together they let a modest home node — the kind a sovereign miner runs to build their own block templates — keep pace with the network on ordinary residential bandwidth, which is precisely the point of keeping a full node cheap to run. Compact blocks rely on the same hashing that produces a transaction's merkle proof; for related block-structure detail see our coinbase commitment entry.