You're a miner. A new block just hit the wire. Your node tears open the compact representation, starts matching 2,500 short IDs against your mempool, and two of them land on nothing. Silence. Now you're waiting on a round-trip request while the rest of the network has already moved on.
That wait is the whole story.
The shortcut, and why it usually works
Bitcoin's compact block protocol (BIP 152, deployed in 2016) is built on one reasonable assumption: if a transaction has been circulating in the mempool for a few seconds, most well-connected nodes have already seen it. So instead of sending a full block, a peer sends a compact version: a block header, a short nonce, and 6-byte truncated transaction IDs derived by hashing each transaction ID against that nonce. The receiver maps those short IDs against its own mempool, reconstructs the full block locally, and never asks for the bulk of the transaction data at all.
On a typical block containing, say, 2,500 transactions averaging 500 bytes each, that's roughly 1.25 MB of payload. The compact representation ships maybe 20-30 KB of IDs instead. For the vast majority of blocks it works exactly as advertised.
The math only holds when the receiver already has the transactions.
What happens when it doesn't
Here's the concrete mechanism of failure. A miner assembles a block that includes a transaction broadcast less than a second before the block was found. A node on the other side of the planet, with slightly higher latency to that miner's peers, hasn't seen it yet. The compact block arrives. The node tries to match all 2,500 short IDs against its mempool. Two of them match nothing.
The protocol then falls back to a round-trip request: the receiver sends a `getblocktxn` message asking for the full data on those two missing transactions, and the miner responds with a `blocktxn` message containing just those transactions. Only then can the receiving node complete the block.
That round-trip is the cost. On a well-connected node with low latency to its peers, it might add 50-100 milliseconds. On a node behind a slow residential connection, or one geographically distant from the originating miner, several hundred milliseconds. For ordinary nodes, that delay barely matters. For miners, it matters quite a lot: every millisecond spent waiting is a millisecond not spent mining on top of the new block, which fractionally increases orphan risk.
Consider two miners, call them Priya and Dmitri, both running full nodes with compact block support. Priya has a direct peering arrangement with the pool that found the block; she reconstructs it without a single round-trip. Dmitri is three hops away and misses four transactions, all of them freshly broadcast high-fee inclusions the winning miner scooped up from a private relay service. His node makes two sequential round-trips before it can validate. He starts mining the next block roughly 600 milliseconds late. Small number. But across hundreds of blocks, that asymmetry compounds into something that shows up in revenue.
The two modes, and what 'high bandwidth' actually buys
BIP 152 defines two operating modes. In low-bandwidth mode, a peer announces a new block with a header and waits to be asked for the compact representation. In high-bandwidth mode, a node pre-authorizes up to three peers to push compact blocks immediately, without waiting for a request. High-bandwidth mode cuts one round-trip from the happy path, which is why well-configured miners use it.
It doesn't touch the fallback.
If your mempool is missing transactions, you still wait, regardless of mode. The protocol cannot compress what the receiver doesn't have. I'd put this more bluntly: compact blocks aren't really a compression scheme at all. They're a deduplication scheme, like checking a shared index before shipping a file you both already have. When the index diverges, the deduplication fails and you're back to sending raw bytes. Calling it compression flatters it.
So what actually reduces the failure rate? Not changing the protocol. Reducing mempool divergence: faster transaction propagation, better peer connectivity, and in the mining world, private mempool-sharing arrangements that ensure high-fee transactions reach all major pools before a block is found. The protocol is downstream of the network's information state, not a fix for it.
Here's the question worth sitting with: if the efficiency gains depend almost entirely on pre-synchronized mempools, who benefits most from those gains? Miners with private relay networks and direct peering arrangements, not the home node operator on a residential connection. The elegant part of BIP 152 is real. So is the quiet tilt it encodes toward well-connected participants.
The compression is nearly free when everyone already knows the same things. When they don't, you're paying for the gap in real time, and the bill isn't split evenly.