When a miner finds a block, speed matters. The longer a block takes to reach other miners, the more likely two blocks compete, and slow propagation favours large, well-connected miners. Yet most transactions in a new block are already in every node's mempool. BIP152, by Matt Corallo, avoids sending them twice. Bitcoin Core has supported it since version 0.13.0 in 2016.
What gets sent
A compact block contains the 80-byte header, a random nonce, a list of 6-byte short transaction IDs and a few "prefilled" full transactions, at least the coinbase transaction. Short IDs come from SipHash-2-4, keyed with a hash of the header and the nonce, so an attacker cannot predict them in advance to create collisions.
Rebuilding the block
The receiver computes short IDs for its own mempool transactions and matches them. If something is missing, it asks with getblocktxn and receives a blocktxn. A short-ID collision is possible but rare. When it happens, the node falls back to downloading the full block.
Two modes
- Low-bandwidth: the peer announces the block as usual, after validating it, and the receiver requests the compact version. This takes 1.5 round-trips, or 2.5 if transactions are missing, but uses far less bandwidth than before.
- High-bandwidth: the peer pushes the compact block straight away, even before fully validating it. If nothing is missing, no extra round-trip is needed at all. Bitcoin Core picks up to 3 peers for this mode.
Versions
Version 1 uses txids. Version 2 uses wtxids, so the short IDs also cover witness data. Modern nodes use version 2.
Why it matters
Faster, lighter block relay lowers the share of stale blocks and makes it cheaper to run a full node. It also reduces the edge that big miners get from fast relay networks.