Witness Commitment

What Is a Witness Commitment?

A witness commitment is a 32-byte hash placed inside the coinbase transaction of every SegWit-containing block. It serves as a cryptographic fingerprint of all the witness data (signatures, redeem scripts, and other authorization proofs) included in the block's transactions. Defined in BIP 141, the witness commitment was activated on Bitcoin mainnet on August 24, 2017, alongside the rest of the Segregated Witness upgrade.

Before SegWit, transaction signatures were included directly in the transaction data, which meant the txid could be modified by anyone who altered the signature encoding. SegWit moved witness data outside the traditional transaction structure, but this created a new problem: how should blocks commit to the witness data if it is no longer covered by the existing Merkle root in the block header? The witness commitment solves this by creating a second, parallel Merkle tree built from witness-inclusive transaction identifiers and anchoring it inside the coinbase transaction.

How It Works

The witness commitment construction involves three steps: computing witness transaction IDs, building a Merkle tree, and embedding the final hash in the coinbase.

1. Each transaction's wtxid (witness transaction ID) is computed by hashing the full serialized transaction including witness data. For non-SegWit transactions, the wtxid equals the regular txid. The coinbase transaction's wtxid is defined as 32 bytes of zeros.
2. These wtxids are assembled into a Merkle tree using the same double-SHA256 construction as the standard transaction Merkle tree. The root of this tree is the witness root hash.
3. The witness root hash is concatenated with a 32-byte witness reserved value (from the coinbase input's witness stack) and double-SHA256 hashed to produce the final commitment hash.
4. This commitment hash is placed in an OP_RETURN output of the coinbase transaction, prefixed by a 4-byte magic header.

Commitment Structure

The commitment output follows a precise byte-level format defined in BIP 141:

scriptPubKey: 0x6a24aa21a9ed[32-byte commitment hash]

Breakdown:
  0x6a       → OP_RETURN (marks output as unspendable)
  0x24       → Push next 36 bytes
  0xaa21a9ed → Commitment header (magic identifier)
  [32 bytes] → Double-SHA256(witness_root || witness_reserved_value)

The total output is 38 bytes minimum. If multiple outputs in the coinbase match the 0x6a24aa21a9ed prefix, the one with the highest output index is treated as the commitment. Bytes after position 38 have no consensus meaning and may carry auxiliary data.

wtxid vs txid

Understanding the difference between txid and wtxid is central to how the witness commitment works:

For non-SegWit transactions, the wtxid and txid are identical because there is no witness data to include. This ensures backward compatibility: every legacy transaction participates in both Merkle trees without modification.

The Witness Reserved Value

The coinbase input's witness stack must contain exactly one item: a 32-byte witness reserved value. Currently this value has no consensus meaning and is typically set to all zeros, but it exists for a specific purpose: enabling future soft fork upgrades.

If Bitcoin introduces a new consensus-critical commitment in the future, the structure extends to:

// Current commitment
commitment = Double-SHA256(witness_root || witness_reserved_value)

// Future extensible commitment
commitment = Double-SHA256(witness_root || Hash(new_commitment || witness_reserved_value))

This design means new commitments can be added without changing the coinbase output format, preserving compatibility with existing validation logic.

Two Merkle Trees: Header vs. Witness

After SegWit, every block effectively contains two parallel Merkle trees that serve different purposes:

The transaction Merkle root in the block header answers "what happened": which UTXOs were spent and created. The witness Merkle root answers "who authorized it": the cryptographic proofs that each spend was legitimate. This separation is the core innovation of SegWit, and the witness commitment is the mechanism that makes it work.

Block Validation Process

SegWit-aware full nodes perform the following steps to validate the witness commitment as part of block validation:

1. Compute the wtxid for every transaction in the block, using all-zero bytes for the coinbase wtxid.
2. Construct the witness Merkle tree from the wtxids and extract the witness root hash.
3. Locate the witness commitment output in the coinbase by scanning for the 0x6a24aa21a9ed prefix. If multiple matches exist, use the output with the highest index.
4. Extract the witness reserved value from the coinbase input's witness stack (must be a single 32-byte entry).
5. Compute Double-SHA256(witness_root_hash || witness_reserved_value) and verify it matches the 32-byte hash in the commitment output.

If any step fails, the block is rejected. Non-SegWit nodes skip this entire process: they see the OP_RETURN output as an unspendable output (a standard pattern they already understand) and validate the block using only the traditional Merkle root. This is why the witness commitment enables SegWit as a soft fork rather than a hard fork.

Why It Matters

Backward Compatibility

The witness commitment was specifically designed to avoid changing the block header format. By nesting the commitment inside the coinbase transaction (which is already committed to by the header's Merkle root), SegWit could activate without requiring every node on the network to upgrade simultaneously. Non-upgraded nodes continue validating blocks under the old rules, seeing SegWit outputs as "anyone-can-spend" scripts. Upgraded nodes enforce the additional witness validation rules.

Transaction Malleability Fix

Because txids no longer include witness data, third parties can no longer modify a transaction's ID by tweaking its signature encoding. The witness commitment ensures that signature data is still cryptographically bound to the block: miners cannot omit or alter witness data without breaking the commitment. This malleability fix was a prerequisite for the Lightning Network and other layer-2 protocols that depend on stable transaction IDs for constructing chains of unconfirmed transactions.

SPV and Future Proof Structures

The extensible commitment structure opens the door for future improvements without additional soft forks to the commitment format itself. BIP 141 describes several potential extensions:

• Compact fraud proofs that allow SPV clients to verify short proofs of block invalidity
• Sum trees for transaction fees, enabling lightweight verification of block constraint compliance
• Backlinks for spent outputs, allowing thin clients to verify that referenced UTXOs actually exist

These extensions would use the witness reserved value mechanism, making them transparent to nodes that do not understand the new rules. For a deeper look at how light clients verify transactions today, see the SPV client deep dive.

Taproot Compatibility

When Taproot (BIP 341/342) activated in November 2021, it introduced SegWit version 1 witness programs. No changes were needed to the witness commitment structure: P2TR transaction wtxids are included in the witness Merkle tree exactly like version 0 transactions. The original design's use of witness versions meant the commitment format was already prepared for this upgrade. For more on how Taproot builds on SegWit, see the Taproot and Schnorr signatures explainer.

Use Cases

Mining and Block Construction

Miners must compute and include the witness commitment when building block templates that contain any SegWit transactions. Mining software calculates the witness Merkle root alongside the standard transaction Merkle root, then constructs the commitment output in the coinbase. Since the vast majority of Bitcoin transactions now use SegWit (approximately 85% as of 2026), the witness commitment is present in virtually every block.

Full Node Verification

Every SegWit-aware full node validates the witness commitment during block verification. This ensures that miners cannot strip or alter witness data after a block is published. Without the commitment, a malicious miner could produce a valid-looking block with fabricated signatures, and non-witness-validating nodes would accept it.

Chain Synchronization

During initial block download, nodes can use the assume-valid optimization to skip signature verification for historical blocks. The witness commitment remains useful even in this mode: it allows nodes to verify the structural integrity of witness data without performing expensive signature checks, and it ensures that the complete witness data was transmitted correctly.

Risks and Considerations

Optional When No Witness Data Exists

If every transaction in a block is a legacy (non-SegWit) transaction, the witness commitment is optional. This edge case is increasingly rare as SegWit adoption exceeds 85%, but software implementations must handle blocks both with and without commitments correctly.

Commitment Ordering Ambiguity

If multiple outputs in the coinbase match the commitment prefix, BIP 141 specifies using the highest output index. Implementations must scan all coinbase outputs rather than stopping at the first match. Incorrect handling of this rule could cause consensus failures between node implementations.

Reserved Value Constraints

The witness reserved value in the coinbase witness stack must be exactly 32 bytes. Any other size causes block rejection. While the value itself currently has no consensus meaning, miners should not use it for non-consensus purposes (such as merged mining commitments) because doing so could conflict with future soft forks that assign consensus meaning to this field.

No Direct SPV Proof for Witness Data

The witness commitment is anchored in the coinbase transaction, not in the block header directly. This means an SPV client that only downloads block headers cannot directly verify witness data. To validate the witness commitment, a client would need the coinbase transaction and a Merkle proof linking it to the block header's transaction Merkle root: an additional round of data beyond what header-only SPV requires.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.