MSG_WITNESS_BLOCK

Two nodes can hold the same block and disagree about how many bytes it is. MSG_WITNESS_BLOCK is code 0x40000002, an ordinary block request with the witness bit added, and it has existed since segregated witness activated at block 481,824 on August 24, 2017. If you run your own node, this is the request that fetches the signatures your machine needs before it will trust the chain.

How it works

Bitcoin Core keeps two ways of writing out the same block and chooses between them based on who is asking.

The witness flag is a single high bit, 0x40000000. Add it to the block inventory type, which is 2, and you get 0x40000002. BIP144 introduced both that flag and the service bit NODE_WITNESS, value 8, which a node advertises in its version message to say it can serve the fuller data. The flag only ever appears in a getdata request. Announcements travel as plain block inventories, because an announcement is just a hash and the hash is the same either way.

That last point is why two serializations can coexist at all. A block header commits to a merkle root built from txids, and a txid is computed over the transaction with its witness removed. Strip every signature out and the block still hashes to the identical 32-byte identifier. Witness data is committed separately, in an output of the coinbase transaction whose script runs to at least 38 bytes and opens with the four-byte tag 0xaa21a9ed followed by a 32-byte witness merkle root.

Size is where the difference bites. The limit on a block is 4,000,000 weight units, counted as three times the stripped size plus the full size, which lets a block loaded with witness data approach 4 MB on the wire. Block 774,628, mined on February 1, 2023, came in at roughly 3.96 MB, nearly all of it one inscription sitting in witness space. Run that weight formula backwards and a block that large has almost nothing left in its stripped form. An old peer asking for the legacy serialization would have received the skeleton and none of the payload, which is precisely why such peers are treated as unable to validate current blocks.

Where you see it

Two places make MSG_WITNESS_BLOCK visible without reading any source code: a node's own logs and its peer statistics.

Start bitcoind with the net debug category and getdata lines scroll past throughout initial block download, every one of them witness-flagged, because a modern node only fetches blocks from witness-capable peers. The getpeerinfo RPC breaks bytes sent and received down per message type, so block traffic is easy to watch dominate a sync. Bitcoin Core 23.0 added getblockfrompeer, which asks one named peer for one specific block by hash, and it retrieves the witness form.

Pruned nodes complicate the picture. A node running with pruning enabled, whose smallest permitted setting is 550 MiB, advertises NODE_NETWORK_LIMITED and serves only the most recent 288 blocks, roughly two days of history. Ask it for anything older and nothing comes back.

For someone buying and holding bitcoin, the meaning is blunt. Verifying the chain yourself means downloading every signature and checking it. A phone wallet that queries a server never sends this request, never sees a witness, and is taking somebody else's word for the balance on your screen.

MSG_WITNESS_BLOCK vs MSG_BLOCK

MSG_BLOCK asks for the same block with the signatures removed, and it is now a legacy request. Both types name a block by the same hash, and both are answered with a block message. The difference is whether the marker and flag bytes and the witness stacks are present inside each transaction. A node that requests MSG_BLOCK for a recent block cannot verify a single segwit spend in it, so Bitcoin Core reserves that form for peers that never signalled NODE_WITNESS.