Witness data

Each input gets its own witness: a stack of items, most often a signature and a public key. The section sits after the outputs, behind a two byte marker and flag that tells software the transaction is in the newer format. A node running software from before the 2017 upgrade never asks for it and never sees it.

How it works

Witness data has its own place in the byte layout of a transaction, defined by BIP-144.

A serialized transaction in the newer format reads: version, the marker byte 0x00, the flag byte 0x01, the inputs, the outputs, then one witness stack per input in the same order, then the locktime. The marker is where the compatibility trick lives, because a value of zero would mean zero inputs under the old parser, which is nonsense, so old software that receives the new format knows immediately that it is not for them and legacy peers are simply never sent it.

Two identifiers come out of this. The txid is a double SHA-256 of the transaction with the marker, flag and witnesses stripped out, which is why nothing inside a witness can alter it. The wtxid hashes the full serialization instead. Every block commits to a merkle root of its wtxids inside a coinbase output, an OP_RETURN whose script is at least 38 bytes and starts with the four byte tag 0xaa21a9ed, so the data is protected even though it lives outside the older commitment.

Cost is where the discount shows up. Anything outside the witness is charged four weight units per byte and anything inside is charged one, against a ceiling of 4,000,000 weight units per block. Divide weight by four and you get virtual bytes, which is the unit fee rates are quoted in.

Where you see it

Open any transaction on a block explorer and the size, virtual size and weight will be printed side by side. When they disagree, the gap is the witness. A payment with no witness at all shows a size equal to its vsize; a Taproot payment can show a vsize barely a quarter of its raw size.

Expanding a single input on a modern explorer shows the stack itself. For a bc1q payment it is two items, a signature around 71 or 72 bytes and a 33 byte compressed public key, and for a Taproot key path spend it is one item of exactly 64 bytes. That count is the entire reason the newer output types are cheaper to spend from.

The field also appears in the files your hardware wallet handles. A partially signed bitcoin transaction has a witness UTXO record and a final witness record per input, which is what a coordinator app is passing back and forth while a multisig transaction collects signatures.

Witness data vs witness script

Witness data is the whole stack; a witness script is one item within it. For a P2WSH spend, the last item on the stack is the script whose hash the output committed to, and everything before it exists to satisfy that script. The relationship copies the older pattern exactly, where a redeem script is the final item of a P2SH signature script. So every witness script is witness data, while most witness data, including every ordinary single key spend, contains no witness script at all.