Bitcoin Compact Block Relay: Faster Blocks, Unchanged Rules
Your pool just found a valid block. The clock is running. Every second that block spends in transit is a second a competing pool might close out that height and orphan your reward before your announcement even reaches half the network. You're not worried about theory right now. You're watching latency eat your margin in real time.
Compact block relay is Bitcoin's answer to that specific, expensive problem. It cuts the bandwidth required to announce a new block by roughly 98%, slashing propagation time from seconds to tens of milliseconds on well-connected nodes. All without touching a single consensus rule.
Why Full Blocks Were Already Too Slow
A standard Bitcoin block runs up to 4 million weight units, somewhere between 1 and 4 MB of actual data. Before compact blocks, the announcing node sent the entire serialized block to each peer. Eight peers meant eight full copies. Those peers did likewise. The block radiated outward through the network like a stone dropped in a pond, and every hop added latency.
The deeper problem was redundancy. A node connected to the network for any length of time has almost certainly already seen and validated the vast majority of transactions inside any given block. A typical block contains 1,000 to 3,000 transactions. Shipping the full transaction data to a peer who already holds most of it is like a restaurant faxing you the entire menu when you called to order the one special you already know about.
The consequences were measurable. Studies of the pre-compact-relay network found median propagation times of 8 to 10 seconds to reach 50% of nodes, and up to a minute for full propagation. For miners, those delays inflated orphan rates and handed a structural edge to pools with better private connectivity.
The Shorthand Trick at the Core of BIP 152
Compact block relay was formalized in BIP 152, authored by Matt Corallo and activated in Bitcoin Core 0.13.0. The mechanism is elegant because it exploits something already true: your peer's mempool is a near-complete copy of the transactions in the incoming block.
Instead of sending full transactions, the announcing node sends three things:
- The 80-byte block header (unchanged from legacy relay)
- A 64-bit nonce chosen at random
- A list of 6-byte short transaction IDs, one per transaction in the block
Those short IDs are derived by running SipHash-2-4 over each transaction's txid, using the block header hash and the nonce as the key. The result is a compact, collision-resistant fingerprint. For a 2,000-transaction block, a complete announcement runs roughly 13 to 15 KB instead of 1 to 2 MB.
When your node receives this compact block, it tries to reconstruct the full block from its mempool. For each short ID, it checks whether it has a matching transaction cached. If it's missing a handful, it sends a `getblocktxn` message requesting only those specific transactions. The announcing node replies with just the missing pieces.
Two modes exist. Low-bandwidth mode is request-pull: you ask a peer for a compact block after learning a new block exists. High-bandwidth mode is push: up to three designated peers will send you compact blocks immediately upon receiving them, without waiting for a request. Miners and well-connected nodes typically configure high-bandwidth mode for their fastest peers.
A Worked Example: Priya and the 3-Transaction Gap
Imagine a node run by Priya. Her mempool holds 2,200 transactions at the moment a new block is found containing 2,203 transactions. Three of those transactions were included by the mining pool from their own fee-bumping logic and hadn't propagated to Priya's mempool yet.
Priya receives a compact block announcement: 80 bytes of header, 8 bytes of nonce, and 2,203 short IDs totaling about 13 KB. Her node processes the list in under a millisecond, matches 2,200 transactions from her mempool, and identifies exactly three missing short IDs. She sends a `getblocktxn` message requesting those three transactions. The responding node sends back perhaps 600 bytes of transaction data. Priya's node reassembles the complete block and begins validation.
Total data exchanged: roughly 14 KB. Without compact relay, she'd have downloaded the full block at perhaps 1.1 MB. The round-trip for the missing transactions adds maybe 20 to 30 ms of latency on a good connection, against the 1 to 2 seconds a full-block download took on a typical consumer connection. Miner orphan rates dropped noticeably after BIP 152 deployment. That's not coincidence.
What People Get Wrong About This
The common misconception is that compact block relay changes how blocks are validated. It doesn't. I want to be direct about this: not one consensus rule is altered. Nodes still validate every transaction, check every signature, verify proof-of-work, and enforce all rules they always did. Compact relay only changes how the raw data gets delivered. The block your node validates at the end is bit-for-bit identical to what it would have received via legacy relay.
So ask yourself: if the validation outcome is identical, why does it matter how the bytes arrive? It matters because time is the variable that drives orphan risk, and orphan risk is what determines whether a found block pays out or gets discarded by the chain.
A related misunderstanding: compact blocks don't eliminate the need for mempool synchronization. If your mempool is badly out of sync (say, you just restarted your node), reconstruction fails for many transactions and you fall back to requesting larger chunks, degrading toward legacy performance. The efficiency gain assumes reasonably synchronized mempools. That's not a flaw. It's an honest reflection of what the protocol is actually doing: a compression scheme that exploits shared state, not a magic bandwidth reducer. The design is precise about its own preconditions, and I think that precision is a feature.
One thing worth naming explicitly: compact blocks help smaller miners too, not only large pools. Before faster propagation was widespread, large pools with private high-speed relay networks (FIBRE, the Fast Internet Bitcoin Relay Engine, being the prominent example) held a measurable latency edge. Compact relay pushed some of that advantage into the public protocol, narrowing the gap without requiring anyone to ask permission.
The Nonce Is Doing More Work Than You'd Think
That random 64-bit nonce isn't decorative. Without it, two different peers sending compact blocks for a given block could generate identical short IDs, and a malicious peer could precompute collisions to cause reconstruction failures. The nonce ensures each sender's short IDs are independently keyed, so a collision crafted for one sender won't affect another. Small detail, real security rationale, baked into the original design.
BIP 152 is a good illustration of a principle that runs through Bitcoin's engineering history: high-impact improvements often aren't new consensus features. They're optimizations to the plumbing. No fork required. Nodes adopting the new behavior interoperate cleanly with nodes that haven't upgraded yet. The network gets measurably faster without anyone being asked to trust anyone else with new powers.
The block still has to be earned. It just doesn't have to be mailed.