Witness Stack

The witness stack is the part of a Segregated Witness (SegWit) transaction input that holds the signatures and any script data needed to satisfy a locking script. Introduced in BIP 141, SegWit moves this unlocking data out of the legacy scriptSig field and into a separate, structured witness field carried alongside the transaction body. The name is precise: the witness is evidence that you may spend, segregated from the description of what is being spent.

How it is structured

Each input has its own witness, expressed as a stack of byte-string items. For a Pay-to-Witness-Public-Key-Hash (P2WPKH) input the witness contains exactly two items: the signature and the public key. For a Pay-to-Witness-Script-Hash (P2WSH) input it contains the arguments followed by the serialized witness script itself, which is hashed and checked against the commitment in the output being spent. Taproot (P2TR) extends the same container: a key-path spend needs only a single Schnorr signature, while a script-path spend carries the arguments, the revealed tapscript leaf, and a control block proving that leaf belongs to the output's commitment. In every case the witness items are pushed onto the script engine's evaluation stack much as scriptSig data once was — but they live outside the portion of the transaction that is hashed to produce the txid.

Why segregation matters

That last detail solved transaction malleability. Because signatures no longer affect the txid, third parties can no longer change an unconfirmed transaction's identifier by tweaking signature encoding — a nuisance that had made chained, presigned transactions unsafe and was a direct blocker for payment channels. Fixing it was a prerequisite for the Lightning Network, whose entire security model rests on presigned transactions whose txids must stay stable. SegWit also gives witness bytes a discount in the block-weight formula — witness data counts one weight unit per byte against four for non-witness data — lowering the effective fee for spending SegWit outputs and raising practical block capacity. Miners and nodes commit to all witness data through the witness commitment in the coinbase transaction, so the segregated data is still fully consensus-bound.

Reading a witness in the wild

The weight discount in numbers

The block-weight formula makes the discount concrete: non-witness bytes count four weight units each, witness bytes one, and a block holds four million weight units. A spender's saving follows directly — a native-SegWit P2WPKH input weighs in around 68 virtual bytes against roughly 148 for its legacy equivalent, because the signature and public key ride in the discounted witness. Multiply across a consolidation transaction with dozens of inputs and the fee difference stops being academic. The same accounting explains why complex scripts migrated to witness outputs: a multi-signature arrangement whose unlocking data would have been expensive scriptSig bytes becomes cheap witness bytes, and under Taproot the cooperative path collapses to a single signature indistinguishable from any other spend. For anyone running coin control on their own wallet, the input type column is effectively a price column — and understanding that the witness stack is where the discount lives is what turns fee estimation from folklore into arithmetic.

For anyone debugging a stuck transaction or building raw spends, the witness stack is where the action is. A malformed witness — wrong item count, non-canonical signature, a witness script that doesn't hash to the output's commitment — is rejected by every validating node, and inspecting the decoded witness usually reveals the fault immediately. Fee estimation also lives here: virtual size depends on how many witness bytes your input type carries, which is why native-SegWit and Taproot spends are cheaper than legacy ones for the same logical payment. The witness stack is the modern replacement for legacy scriptSig data and feeds the same evaluation model described under the script stack; SegWit's script-hash variant is the witness-era analogue of Pay-to-Script-Hash (P2SH).