Your node gets a compact block announcement. It runs the short ID list against its mempool, ticks off matches one by one, and then stops on a transaction it has never seen. Then another. Then six more. What should have been a sub-millisecond local assembly job has just become a round-trip request to a peer two hundred milliseconds away, and a miner somewhere is bleeding expected revenue while your node catches up.

That's compact block reconstruction breaking down under mempool divergence. It doesn't threaten Bitcoin. But it reveals something precise and honest about how the network actually moves blocks around, and it's worth understanding properly.

What Compact Blocks Are Actually Doing

Before BIP 152 shipped in 2016, every new block meant sending the whole thing: header, every transaction, all the bytes. For a block stuffed with 2,500 transactions, that's a few megabytes traveling to every connected peer. Multiply by thousands of nodes and you get meaningful propagation lag.

Compact blocks changed the contract. Instead of sending full transactions, the announcing node sends a block header plus a list of short transaction IDs, each one a 6-byte truncated hash. The receiving node looks up those short IDs against its own mempool. If it already has the transaction locally, it doesn't need to ask for it again. The reconstructed block is assembled from what's already sitting in memory.

The bandwidth saving is real and large. A compact block announcement might be 20-40 kilobytes where the full block would be 1.5 megabytes. For well-connected nodes with overlapping mempools, reconstruction completes in milliseconds.

The catch is that word: overlapping.

The Reconstruction Failure Cascade

When a node receives a compact block, it runs through the short ID list and tries to match each one against its mempool. Any transaction it can't match becomes a "missing" entry. Once the list is exhausted, if missing entries exist, the node sends a `getblocktxn` message back to the peer, requesting those specific transactions by index.

The peer responds with a `blocktxn` message containing the missing transactions. The node reconstructs, validates, forwards.

That round trip costs time. On a well-peered network, a transatlantic request-response cycle runs 50-200 milliseconds. Not catastrophic by itself. The problem compounds when divergence is high and many transactions are missing, because now you've traded a single large data transfer for a large data transfer plus a full round trip of latency stacked on top.

Consider two node operators. Priya runs a node in Singapore that she keeps tightly synced, fee filtering set low enough that she holds most of the economically relevant mempool. Her compact block reconstruction succeeds on the first pass roughly 97% of the time. Marco runs a node in the same city, but he configured aggressive fee filtering 18 months ago to save memory, and his node has been sitting behind a NAT with only 4 outbound connections ever since. His mempool has drifted. He misses 15-30 transactions per block on average. Every block hits him as a partial reconstruction failure, adding that round trip, and his validation times run consistently 300-500 milliseconds slower than Priya's.

For a home user, Marco's situation is an annoyance. For a miner, it's a revenue problem.

Why Miners Care About This More Than Anyone

Block propagation speed is a competitive variable in mining. Every millisecond a miner spends waiting for block data to arrive and validate is a millisecond spent either mining on an incomplete chain or sitting idle. The stale block rate, the share of valid blocks orphaned because a competing block arrived first, is directly tied to propagation speed across the network.

The Bitcoin network runs on roughly 10-minute average block intervals. A 500-millisecond propagation disadvantage represents about 0.08% of that interval. Across thousands of blocks a year, that's real expected revenue lost, not a rounding error.

This is why industrial mining operations don't rely on standard peer-to-peer compact block propagation at all. They use dedicated relay networks (FIBRE and its successors), which push pre-validated block data over UDP channels with forward error correction. The mempool divergence problem gets sidestepped entirely: the relay network isn't asking your local mempool to fill in gaps, it's sending you what you need proactively, like a courier who doesn't wait to be asked.

For the rest of the network, the fix is simpler and less glamorous: keep your mempool healthy.

What People Get Wrong About This

The common assumption is that mempool divergence is mainly a fee-filtering problem. True, but incomplete. The other three sources matter just as much and get a fraction of the attention.

Transaction propagation timing. A transaction broadcast one second before a block is found may have reached 70% of nodes but not the other 30%. Those nodes fail to reconstruct that transaction not because of fee policy but because it simply hadn't arrived yet. This is a fundamental race condition the protocol accepts as a design trade-off, and no amount of mempool tuning eliminates it.

RBF replacements. If a transaction was replaced in-flight, some nodes hold the original version, some hold the replacement, and the miner included the replacement. Short IDs are computed from the actual transaction data, so a node holding the wrong version gets a mismatch and falls back to an explicit request. This catches people off guard.

Non-standard transactions. Nodes with default policy settings reject certain transaction types from their mempools entirely. When a miner includes a non-standard transaction (permitted at the consensus level, just filtered by default policy), every standard node fails to match it during reconstruction. Rare, but worth knowing as new script types keep emerging.

If you're seeing frequent `getblocktxn` exchanges in your debug log, the fastest fix is usually increasing your `maxmempool` setting and relaxing `minrelaytxfee` to match the broader network's acceptance threshold. It won't get you to Priya's 97% first-pass rate overnight, but it closes most of the gap.

The Number That Matters

BIP 152 defines two modes: high-bandwidth, where a peer sends compact blocks speculatively before being asked, and low-bandwidth, where the peer waits for a request. High-bandwidth mode only earns its name when mempool overlap is high, because a speculative send that triggers multiple round trips is strictly worse than just sending the full block.

The threshold isn't a hard protocol rule. It's an emergent network reality. Empirical measurements from researchers across Bitcoin's history have found that reconstruction failure rates climb sharply once mempool overlap drops below roughly 85-90%. Below that range, the latency cost of `getblocktxn` round trips begins to exceed the savings from the compact block format itself.

That 85% figure is the real answer to the question most people are actually asking. Compact blocks don't fail catastrophically below some cliff edge. The efficiency gain shrinks steadily as divergence grows, until at high enough divergence you're paying the round-trip tax on top of most of the original data transfer. The format becomes self-defeating.

The protocol is elegant. The network is messy. Compact blocks work brilliantly when nodes are well-maintained and well-connected, which is an argument for both, not a criticism of the design.