Witness

The witness is the part of a SegWit transaction that holds the data unlocking its inputs, mostly signatures and public keys. Outputs locked with the SegWit scripts, such as P2WPKH, P2WSH and P2TR, read their unlocking data here instead of from the scriptSig field.

Because the witness sits apart from the rest of the transaction, it counts for less toward a block's size limit, and it does not change the TXID. This page covers its layout, a real example, and why it exists.

Where does the witness sit in a transaction?

A SegWit transaction carries two extra bytes right after its version: a marker (00) and a flag (01). They tell a parser that a witness section follows. A legacy transaction has neither the marker and flag nor a witness, so its layout is shorter.

The inputs and outputs look the same in both kinds. The witness comes after the outputs, and the four-byte locktime closes the transaction.

What does a witness field hold?

Every input gets its own witness field, in the same order as the inputs. Each field starts with a count of stack items, written as a compact size number. Each item then comes with its own length and its bytes.

Unlike a scriptSig, a witness field contains no opcodes. It only pushes data onto the stack. A signature and a public key are enough to unlock the common locks, so the witness does not need the full script language.

Here is a real witness. Input 0 of transaction 7a466b5e… in block 795,157 spends a P2WPKH output, and its witness field has two items:

Field	Value	Bytes
Stack items	02	1
Item 1 length	47 (71 in decimal)	1
Item 1: signature	DER-encoded, ends in 01 (SIGHASH_ALL)	71
Item 2 length	21 (33 in decimal)	1
Item 2: public key	compressed, starts with 03	33
Total		107

The full signature is:

304402202a11945f55d174686cd48e9b3e0db3bfbe5fb9557a76fa546c6772c434f03f14022010be503e37c1cb6e0519ce9f8532c89fa2cbec6667d93a4f3bdef43fb047dba301

The public key is 032704e02eb63d8ea323b0386bf3b47c0d9058f36c9c486ac102a34b929d862abb. The lock on the spent output is a hash of that key, so the node checks the key against the lock, then checks the signature against the key. For how signatures work, see signature.

A witness has no opcodes, so pushing data is its only job. A scriptSig can push the number 8 with the opcode OP_8. A witness pushes the same number as a one-byte item instead, written 0108: a length byte of 01, then the byte 08.

What do P2WSH and P2TR witnesses hold?

A P2WSH witness ends with the witness script itself. The items before it unlock that script. For a 2-of-3 multisig, they are two signatures, with an empty item in front. The empty item exists because OP_CHECKMULTISIG takes one extra item off the stack, a long-standing quirk. The P2WSH page covers the script side.

A P2TR witness has two shapes. In a key path spend it holds one item, a Schnorr signature of 64 bytes, or 65 bytes when it adds a sighash byte. In a script path spend it holds the script inputs, the leaf script and a control block. The control block proves that the leaf script belongs to the output's script tree. The Taproot page explains both paths, and BIP 341 defines them.

Why does the witness weigh less?

Bitcoin counts a transaction's size in weight units, and the witness counts once per byte while the rest of the transaction counts four times. This is the SegWit discount.

The discount reflects a real imbalance. Spending an output needs a signature, which is much bigger than the lock that was put on the output. Charging the full price for the signature would make spending cost far more than creating an output. The size page works through the arithmetic.

The numbers from this page's example show the gap. A legacy P2PKH unlocking code in a scriptSig is 106 bytes, which is 106 virtual bytes. The P2WPKH witness above is 107 bytes, which counts as only 26.75 virtual bytes.

Does the witness change the TXID?

Before SegWit, a signature could be altered slightly without changing what a transaction did, and the altered version had a different TXID. That made it possible to change a transaction's ID before it was mined, so a wallet tracking the old ID could lose sight of its payment.

Moving signatures into the witness fixed this for SegWit inputs. The TXID is calculated without the witness, so it stays the same. The hash that does include the witness is the wTXID.

What is the witness reserved value?

The first transaction in every block is the coinbase. Its one input spends nothing, so the unlocking part of that input has no job to do. Its witness holds a single 32-byte item called the witness reserved value, which is all zeros today.

The reserved value is space kept for a later upgrade. Blocks use it, together with the wTXIDs, to commit to the witness data. For the example in block 553,724, the coinbase transaction is 2d4cdcd2…, and its witness is 32 zero bytes. The wTXID page explains that commitment.

Can a transaction mix legacy and SegWit inputs?

Yes. Every input still gets its own witness field, even a legacy one. A legacy input has nothing to put in its field, so it stores a single 00, which means zero items. The SegWit inputs fill theirs as usual.

How large can a witness be?

Bitcoin Core limits the size of the witness in a standard P2WSH spend. A witness can hold at most 100 stack items. Every item except the witness script can be 80 bytes at most, and the witness script itself can be up to 3,600 bytes.

A transaction over these limits can still be valid, but nodes will not relay it as standard. The limits live in Bitcoin Core's policy code, not in the consensus rules, so they can change without a change to the protocol.

Why is it called a witness?

Pieter Wuille, a developer of SegWit, explained the name by comparison with mathematics. In mathematics, a witness shows that something exists by giving one example. For a transaction, the witness shows that the owner authorized the spend, without changing what the transaction does. A transaction can have many valid signatures, and the network only needs to see one of them.

Sources

• BIP 141: Segregated Witness defines the witness, the marker and flag, and the weight rules.
• BIP 141, transaction size calculations gives the multipliers used in the size page.
• BIP 341: Taproot defines the witness shapes for P2TR spends.
• Bitcoin Core policy constants sets the witness limits for standard spends.