Compact Blocks are a way to relay Bitcoin blocks under BIP 152 while repeating less data. They do not shrink the block itself or relax its rules: the receiver must recover the complete contents and verify them before acceptance.
Anna wants to send Peter a new block, but he already has many of its transactions. A block groups transactions into a batch added to the shared history. Sending them all would repeat information. Compact Blocks instead provide a block header and a list of short labels that Peter can match to known transactions. The header is a short part of the block containing basic information, including a reference to the previous block and a fingerprint of the transactions. For technical readers: these labels are 48 bits, or 6 bytes, produced by truncating the output of the SipHash-2-4 function. Its parameters derive from the header and an extra number used for this relay, called a nonce. A label is therefore not a permanent transaction name for the entire Bitcoin network. [1] [2] [7]
A list cannot replace everything. Anna sends selected transactions in full, together with their positions in the block. A usual example is the Coinbase Transaction, the block’s first transaction, which assigns the mining reward; it is unrelated to the exchange with the same name. It is created for that particular block, so Peter will not normally have it among his waiting transactions. Full entries and short labels complement each other during reconstruction. [1] [2]
Peter’s Mempool is his local collection of transactions his node knows but has not yet confirmed in its accepted chain. He computes the same short labels for available transactions and looks for matches with Anna’s list. He does not assume everyone has an identical collection. Since a short label can occasionally match more than one transaction, a match alone is not final proof that the contents are correct. [1] [2]
If positions remain empty or ambiguous, Peter requests specific transactions by their positions. The request message is called getblocktxn, and the reply carrying transactions is blocktxn. You need not memorize those names: what matters is requesting real data rather than guessing the contents. Another trip across the network and back costs time. If reconstruction fails, the full block can be downloaded. [1] [3]
Peter must recover the exact transactions in their correct order and check their connection to the header. A Merkle Tree combines transactions into a checking fingerprint and helps verify such connections. Correct assembly still does not replace checking the rules. A Full Node is software Peter uses to check Bitcoin’s rules independently, including permission to spend funds and the amount of the reward. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. Compact relay grants no exemption for an invalid block. [1] [8]
Neighbouring nodes agree on a mode using sendcmpct. In the faster option, a cmpctblock message carrying reconstruction data directly announces the new block. After specified preliminary checks, the sender may start relaying before finishing every transaction check. It must check, among other requirements, the link to the validated chain, Proof of Work, the evidence of computational work, and the header’s commitment to the transactions. The receiver still fully verifies the block before accepting it into its history. [1] [4]
The other option first announces an already validated block through inv or headers. Peter then requests compact data if he needs them. This can avoid an unnecessary delivery of a block he has obtained elsewhere, at the cost of another communication step. Both modes can save data compared with sending all transactions again; they differ in when data are sent and whether a prior request is needed. They are not different standards of block validity. [1] [7]
Two different transactions can have the same short label. This is called a collision. Think of two people sharing initials: the abbreviation is no longer enough to distinguish them. Depending on where the problem occurs, the software requests clarification or falls back to a full block. A collision does not break Bitcoin signatures or turn an invalid block into a valid one. The actual contents must be checked, not just matching short labels. [1] [2]
Version 2 of the compact protocol supports SegWit, the change that separates signatures and other verification data into a witness portion. It uses wtxid, an identifier including those data, instead of txid, which excludes them. Full transactions are transmitted with the required witness data according to BIP 144. Those data are not simply discarded to make the delivery look smaller. The relay protocol’s version is also distinct from the block’s own version number. [1] [6]
When Anna and Peter share many transactions, news of the block travels with much less repeated data. That also helps a home connection cope with the sudden arrival of a block. With little overlap, additional requests reduce the savings. The main goal is to save transmission data; quicker delivery is a possible benefit, not a promise of zero waiting or one fixed message size. It does not introduce a new Bitcoin block size limit. [5] [7]
For the clearest picture, read this entry together with Block Propagation, Initial Block Download, Eclipse Attack, vByte, Bitcoin, Coinbase transaction. The reverse links also lead from Stale Block, Eclipse Attack, Selfish Mining, Block Propagation.