Witness Stack

What Is the Witness Stack?

The witness stack is the data structure that stores cryptographic proof data for spending Bitcoin outputs in Segregated Witness transactions. Before SegWit, signatures and public keys lived inside the scriptSig field of each transaction input. SegWit moved this data into a separate witness structure that sits between the outputs and the locktime in the serialized transaction format.

Each input in a SegWit transaction has its own witness stack: an ordered list of byte arrays that the script interpreter pops from during validation. The stack is serialized with a var_int indicating the number of items, followed by each item prefixed with its own length. For legacy (non-SegWit) inputs, the witness stack is empty, represented as a single 0x00 byte.

This separation was the key innovation that solved transaction malleability: because the witness is excluded from the transaction ID (txid) calculation, changes to signature encoding no longer alter the txid. This fix was a prerequisite for building reliable payment channel networks like the Lightning Network, where chains of unconfirmed transactions reference each other by txid.

How It Works

A SegWit transaction uses a modified serialization format defined in BIP 141. The layout includes a marker byte (0x00) and a flag byte (0x01) after the version field, signaling that witness data is present:

[version] [marker: 0x00] [flag: 0x01] [inputs] [outputs] [witness] [locktime]

The witness section contains one witness stack per input, in the same order as the inputs. Each stack begins with a count of items, and each item is a length-prefixed byte array. The script interpreter loads these items onto the evaluation stack before executing the witness script or witness program.

txid vs. wtxid

SegWit introduced two transaction identifiers. The traditional txid is computed by hashing the transaction without the marker, flag, and witness fields. The wtxid hashes the full serialized transaction including witness data. Nodes use the wtxid for relay and block witness commitments, while the txid remains the canonical identifier for spending outputs.

Witness Stacks by Output Type

The contents of the witness stack depend on which type of output is being spent. Each witness version and program length implies different validation rules:

P2WPKH Witness Stack

A P2WPKH output is the SegWit equivalent of P2PKH. The witness stack must contain exactly two items: a DER-encoded ECDSA signature and a compressed public key. The HASH160 of the public key must match the 20-byte witness program in the output script. This is the simplest and most common SegWit witness format:

Witness stack (P2WPKH):
  Item 0: <signature> (71-73 bytes, DER-encoded ECDSA)
  Item 1: <public_key> (33 bytes, compressed)

P2WSH Witness Stack

A P2WSH output is the SegWit equivalent of P2SH. The last item on the witness stack is the serialized witness script, and all preceding items are pushed onto the script interpreter's stack before the script executes. The SHA-256 hash of the witness script must match the 32-byte witness program. BIP 141 imposes a consensus limit of 10,000 bytes on the witness script.

Witness stack (P2WSH 2-of-3 multisig):
  Item 0: <empty>       (OP_CHECKMULTISIG bug workaround)
  Item 1: <signature_1>
  Item 2: <signature_2>
  Item 3: <witness_script>  (OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG)

P2TR Witness Stack

Taproot (P2TR) outputs support two spending paths, each with a different witness layout. For a key-path spend, the witness contains a single Schnorr signature (64 bytes with the default sighash type). For a script-path spend, the witness contains any script input data, the Tapscript being executed, and a control block that proves the script was committed in the Taptree:

Witness stack (P2TR key path):
  Item 0: <schnorr_signature> (64 bytes)

Witness stack (P2TR script path):
  Item 0..n: <script_input_data>
  Item n+1:  <tapscript>
  Item n+2:  <control_block> (33 + 32m bytes, m = Merkle path depth)

If at least two witness elements exist and the last element starts with byte 0x50, that element is treated as the annex and is removed before the key-path or script-path check. The annex is covered by the signature but is otherwise ignored during validation.

The Witness Discount

SegWit introduced a new fee calculation based on weight units rather than raw bytes. Non-witness data (version, inputs, outputs, locktime) counts at 4 weight units per byte, while witness data counts at 1 weight unit per byte. The block limit was set at 4 million weight units, replacing the previous 1 MB byte limit.

This 4:1 ratio means witness bytes are 75% cheaper than non-witness bytes in terms of fees. Transaction fees are calculated using virtual bytes (vbytes), where 1 vbyte equals 4 weight units. The witness discount incentivizes moving data into the witness, which increases effective block capacity without a hard fork.

The rationale for discounting witness data is that signatures are only needed during validation, not for tracking the UTXO set. Nodes that have already validated a block can prune witness data without losing the ability to verify chain state. Non-witness data, by contrast, defines outputs that must be tracked until spent.

Why It Matters

The witness stack was not just a data format change: it was the foundation for several major Bitcoin upgrades and protocol developments.

• Transaction malleability fix: by excluding witness data from the txid, SegWit eliminated third-party malleability where relayers or miners could alter a transaction's identifier by tweaking its signature encoding. This made it safe to build chains of unconfirmed transactions, directly enabling Lightning Network payment channels.
• Capacity increase: the witness discount effectively raised the block capacity from 1 MB to a theoretical maximum of about 4 MB (in practice, typical blocks are 1.5 to 2.5 MB). For a deeper look at how this affects on-chain fees, see the fee market dynamics analysis.
• Taproot enablement: the witness versioning system in BIP 141 created a clean upgrade path. Version 0 defined P2WPKH and P2WSH, while version 1 introduced Taproot with Schnorr signatures and Tapscript. Future witness versions can add new spending rules without another soft fork. For a comprehensive look at how Taproot builds on the witness stack, see the Taproot and Schnorr signatures research article.
• Layer 2 protocols: Spark and other Bitcoin layer 2 solutions rely on the malleability fix and the efficient witness format. Protocols that build on pre-signed transactions, such as statechains and payment channels, need stable txids to function correctly.

Use Cases

Standard Payments

Every SegWit and Taproot transaction uses the witness stack for its authorization data. A simple payment from a P2WPKH address places the signature and public key in the witness rather than the scriptSig, reducing the transaction's effective size and the fee the sender pays.

Multisig and Complex Scripts

P2WSH transactions place multisig signatures and the redeem script in the witness stack, where they receive the fee discount. A 2-of-3 multisig transaction saves roughly 40% on fees compared to its legacy P2SH equivalent because the signatures and script are witness data.

Taproot Privacy and Efficiency

Taproot key-path spends produce the smallest possible witness stack: a single 64-byte Schnorr signature. This makes a complex spending policy (multisig, timelocks, hash locks) indistinguishable from a simple single-key payment on chain. The script is only revealed if the key-path cannot be used, and even then, only the specific branch that is executed appears in the witness.

Inscriptions and Data Embedding

The witness discount has also enabled inscriptions (Ordinals), which embed arbitrary data in the witness stack using Tapscript envelopes. Because witness data costs one-quarter the fee of non-witness data, storing images, text, or other media in the witness is significantly cheaper than alternatives like OP_RETURN.

Risks and Considerations

UTXO Set Bloat vs. Witness Discount

The witness discount was designed to incentivize spending UTXOs (which shrinks the UTXO set) by making the witness-heavy spending data cheaper relative to output-heavy data. However, the discount also makes it cheaper to store large amounts of data on chain via inscriptions, which has increased block sizes and storage requirements for full nodes.

Witness Size Limits

Individual witness stack items are limited to 520 bytes for version 0 witness programs (P2WPKH and P2WSH). Tapscript (version 1) removes the 520-byte item limit but retains other consensus limits. The total witness for a single input contributes to the overall block weight limit of 4 million weight units.

Backward Compatibility

SegWit was deployed as a soft fork, meaning older nodes treat witness outputs as "anyone can spend." These nodes do not validate witness data, so they accept SegWit transactions without verifying signatures. This is safe in practice because miners enforcing SegWit rules will reject invalid witness data, but it means pre-SegWit nodes provide weaker security guarantees.

Witness Malleability

While SegWit eliminated third-party txid malleability, the witness itself can still be malleated in certain edge cases. For example, additional stack items beyond those required by the script could theoretically be added. BIP 141 includes rules to constrain valid witness formats (such as requiring exactly two items for P2WPKH), and BIP 340 Schnorr signatures eliminate signature-level malleability entirely through deterministic encoding.

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.