Witness Commitment

The witness commitment is the mechanism SegWit (BIP-141) uses to bind a block to its segregated witness data. Because SegWit moved signatures and other witness data out of the part of a transaction covered by the original Merkle root, a second commitment was needed so that witnesses could not be altered after the fact — and it had to be added in a way that older nodes would still accept. The result is an elegant piece of protocol archaeology: a new commitment structure grafted onto the one place in a block that miners fully control, the coinbase transaction.

How the commitment is built

Every transaction has both a TXID (a hash of its non-witness data) and a WTXID (a hash that also includes the witness). Nodes build a separate Merkle tree from all the WTXIDs in the block, producing a witness root hash; by convention the coinbase's WTXID is set to all zeros in this tree, since the coinbase's own witness holds the reserved value. That root, combined with a witness reserved value carried in the coinbase's witness field, is double-SHA256 hashed and placed inside an output of the coinbase transaction — an OP_RETURN script beginning with the marker bytes 0x6a24aa21a9ed. Any block containing SegWit transactions must carry this commitment, and a block whose witness data does not match it is invalid to upgraded nodes.

Why put it in the coinbase

The block header's Merkle root only commits to TXIDs, and changing the header format would have been a hard fork. Embedding the witness commitment in the coinbase — itself already covered by the header's Merkle root — lets the witness data be committed transitively while keeping SegWit a backward-compatible soft fork. Old nodes simply ignore the extra coinbase output as an unspendable data output, while upgraded nodes enforce the full commitment. It is a textbook example of Bitcoin's upgrade discipline: extend what exists rather than break what deployed.

What it means for miners

The witness commitment is a miner-side responsibility. Whoever assembles the block template — in practice the pool server for pooled miners, or your own node when solo mining — must compute the witness root and insert the commitment output before work is handed out. This is one reason coinbase construction is more intricate than it looks, and why protocols that let miners build their own templates must carry enough data to do it correctly. Get the commitment wrong and the block is worthless: full nodes reject it regardless of how much proof-of-work it carries.

The malleability fix that unlocked everything after

This design is also what finally fixed transaction malleability: since a transaction's TXID no longer depends on its mutable signature data, third parties can no longer change a TXID in flight by tweaking a signature encoding. That single property is what made chains of pre-signed, unconfirmed transactions safe — the foundation the Lightning Network is built on — and cleared the path for later upgrades such as Taproot, which extends the same witness architecture.

You can inspect all of this yourself. Any block explorer — or better, your own node with getblock at full verbosity — shows the coinbase transaction's outputs, and the commitment output is easy to spot by its aa21a9ed marker. The witness reserved value sitting in the coinbase witness is itself a quiet piece of forward planning: it currently carries no meaning, but it gives future soft forks a place to commit to additional data without touching the header, the same trick SegWit itself used. Bitcoin's upgrade history is full of these deliberately reserved footholds, and the witness commitment is where the next ones are likely to anchor.

For the propagation optimization that builds on these transaction IDs, see D-Central's entry on Compact Blocks, and on inclusion proofs see SPV.