A compact block is a transport encoding, not a smaller consensus block. A Full Node must recover the exact transactions in the correct order and validate the entire block.
A short ID contains 48 bits obtained by truncating SipHash-2-4. Keys derive from the header and supplied nonce; it is not a global transaction identifier. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation]
Some transactions arrive in full as prefilled entries, normally including the coinbase. Their indexes specify positions in the reconstructed block. [BIP 152 — Compact Block Relay]
The receiver matches short IDs against known transactions, for example in its mempool. An identical short ID alone does not prove transaction identity. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation]
Missing or ambiguous entries are requested by index through getblocktxn. The blocktxn response supplies the requested transactions to finish reconstruction. [BIP 152 — Compact Block Relay] [Bitcoin Developer Reference — P2P] [Bitcoin Core v29.0 — net processing]
Reconstruction preserves exact transaction order and checks block commitments. A Full Node still performs consensus validation before acceptance; compact relay is no exemption. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation] [Bitcoin Core v29.0 — net processing]
After sendcmpct negotiation, high-bandwidth mode can send cmpctblock directly as an announcement. Following specified preliminary checks, it can precede the sender's full validation without removing receiver validation. [BIP 152 — Compact Block Relay] [Bitcoin Core v29.0 — net processing]
Low-bandwidth mode first uses ordinary inv or headers announcements, after which the receiver requests a compact block. It may therefore require more round trips than direct announcement. [BIP 152 — Compact Block Relay] [Bitcoin Developer Reference — P2P]
Short-ID collisions can cause transaction requests or reconstruction failure followed by downloading the full block. They do not allow an incorrect block to be accepted as consensus-valid. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation] [Bitcoin Optech — Compact block relay]
Version 2 derives short IDs from wtxid rather than txid and transmits transactions with witness data under BIP 144. The compact protocol version is not the block's own version number. [BIP 152 — Compact Block Relay] [BIP 144 — SegWit peer services]
Benefits depend on transaction overlap and network conditions. Poor overlap adds requests; the main aim is bandwidth savings, not a guaranteed message size or zero latency. [BIP 152 — Compact Block Relay] [Bitcoin Optech — Compact block relay]
For the clearest picture, read this entry together with Block propagation, Initial block download, Eclipse attack, Virtual byte (vbyte). The reverse links also lead from Block propagation, Compact Block Filters, Compact Block Filters, Matt Corallo.