Witness commitment

Segregated witness needed to record a second merkle root without touching the block header, and BIP-141 puts it in a coinbase output so the change could ship as a soft fork. The script must run to at least 38 bytes and open with 0x6a24aa21a9ed. The commitment binds the signatures that authorize your coins to the block that mined them, since a txid leaves witness data out by construction.

How it works

BIP-141 specifies the witness commitment down to the opcode, and a node recomputes the value before accepting the block.

Nodes build a second merkle tree over the block, using wtxids as leaves in place of txids and combining them the way the header's own tree is built. The coinbase transaction's own leaf is not its real wtxid: BIP-141 assumes that value to be 32 zero bytes, because the number being computed lives inside that very transaction and nothing can hash itself. What gets written into the output is a double SHA-256 of the witness root hash joined to a 32 byte witness reserved value, and that reserved value has to appear as the single item in the coinbase input's own witness field.

Byte by byte, the output script reads: one byte of OP_RETURN (0x6a), one byte pushing the next 36 (0x24), a four byte commitment header (0xaa21a9ed), then the 32 byte hash. Those add to 38 bytes, and anything from the 39th byte onward is optional data with no consensus meaning.

Two edge rules stop the pattern being gamed or over-applied. Where several outputs match, the one at the highest output index counts, so a decoy placed earlier cannot displace the real value. And where no transaction in a block carries witness data, the commitment is optional. The rule shipped through BIP9 version bits under the name segwit on bit 1, with a mainnet signalling window from midnight 15 November 2016 UTC to midnight 15 November 2017 UTC.

Where you see it

A witness commitment appears on a block explorer as an output of the coinbase transaction whose script begins with OP_RETURN.

Open the first transaction of any recent block and the outputs fall into two kinds: the ones paying the pool and its customers, and one whose script hex opens 6a24aa21a9ed. The 32 bytes after that prefix are the commitment itself, and anything past the first 38 bytes is free space.

Mining software meets the field more often than anyone else does. The value is a hash over every wtxid in the block, so it has to be recomputed whenever the candidate transaction set changes, and written back into the coinbase before the header is hashed at all.

The reserved value is the part worth watching. BIP-141 gives it no consensus meaning today and holds it back deliberately, so that a future soft fork can nest a new commitment inside the existing one by hashing the new value together with the reserved value first. The document forbids non consensus uses such as merge mining from taking that space, and names what it is being saved for: sum trees over fees, counters for block size and sigops, and backlinks to the outputs a transaction spends. Together those would hand a light client a short proof that a block is invalid rather than the block itself.

Witness commitment vs merkle root

The witness commitment and the merkle root are the roots of two separate trees, and only one of them holds a place in the block header.

The merkle root is a header field whose leaves are txids, and a txid by construction excludes witness data. The witness commitment lives in a transaction output, its leaves are wtxids, which include that data, and its coinbase leaf is zeroed. Nesting is the whole trick. The coinbase transaction sits in the older tree as a leaf like any other, so editing the commitment changes the coinbase, changes the header's merkle root, and breaks the block even for software that never heard of segregated witness.