Witness Version

What Is a Witness Version?

A witness version is a version byte embedded in the scriptPubKey of a SegWit output. Introduced by BIP 141 (Segregated Witness), it acts as a routing label: when a node encounters a SegWit output, the witness version tells it exactly which set of script validation rules to apply when someone tries to spend that output.

Before SegWit, upgrading Bitcoin's scripting capabilities required repurposing existing opcodes or introducing entirely new transaction formats. The witness version system solved this by reserving 17 version slots (0 through 16), each of which can define completely new spending rules. Only two versions are currently active: version 0 for standard SegWit outputs and version 1 for Taproot outputs.

How It Works

Every SegWit output follows a strict two-part scriptPubKey format: a one-byte version push followed by a data push containing the witness program. The version byte is a Bitcoin Script opcode, and the witness program is a hash or public key that defines the spending condition.

ScriptPubKey Structure

The scriptPubKey consists of exactly two pushes:

1. Version byte: OP_0 (0x00) for version 0, or OP_1 through OP_16 (0x51 through 0x60) for versions 1 through 16
2. Witness program: a direct data push of 2 to 40 bytes containing the hash or key that locks the output

# General format
[version-opcode] [push-length] [witness-program]

# P2WPKH (version 0, 20-byte hash)
OP_0 0x14 <20-byte HASH160 of pubkey>
# Hex: 0014{20-byte-hash}

# P2WSH (version 0, 32-byte hash)
OP_0 0x20 <32-byte SHA256 of witness script>
# Hex: 0020{32-byte-hash}

# P2TR (version 1, 32-byte key)
OP_1 0x20 <32-byte x-only tweaked pubkey>
# Hex: 5120{32-byte-key}

Note the gap in opcode values: OP_0 is 0x00, but OP_1 starts at 0x51. This is because opcodes 0x01 through 0x4e in Bitcoin Script are reserved for data push operations. The witness version uses the "push number" opcodes instead.

Version 0: P2WPKH and P2WSH

Witness version 0, activated on August 24, 2017 at block 481,824, defines two output types based on the length of the witness program:

• 20-byte witness program: interpreted as P2WPKH (Pay-to-Witness-Public-Key-Hash). The witness must contain exactly two items: a signature and a public key. The node verifies that the HASH160 of the public key matches the 20-byte program, then checks the signature.
• 32-byte witness program: interpreted as P2WSH (Pay-to-Witness-Script-Hash). The witness contains a stack of inputs plus a serialized witness script. The node verifies that the SHA256 of the witness script matches the 32-byte program, then executes the script.

Any other witness program length for version 0 causes the script to fail. P2WSH uses SHA256 (rather than HASH160) to provide 128-bit collision resistance, which matters for scripts where multiple parties contribute inputs.

Version 1: Taproot (P2TR)

Witness version 1, activated on November 14, 2021 at block 709,632, defines P2TR (Pay-to-Taproot) outputs. The 32-byte witness program is an x-only public key (just the X coordinate of a secp256k1 point), as specified by BIP 340.

P2TR outputs can be spent through two paths:

• Key path: the witness contains a single Schnorr signature (64 or 65 bytes). This looks identical to a simple single-key spend, providing privacy regardless of how complex the underlying spending conditions are.
• Script path: the witness contains stack inputs satisfying a script, the script itself, and a control block with a Merkle proof. Complex spending conditions are committed in a Merkleized tree (MAST), and only the executed script branch needs to be revealed on-chain.

For a detailed breakdown of both spending paths, see the research article on P2TR spend paths.

Versions 2 through 16: Reserved

Versions 2 through 16 are reserved for future upgrades. Per BIP 141, nodes do not interpret the witness program or validate the witness stack for unrecognized versions. This means new features can be added behind a new version number without any risk of breaking existing nodes.

One notable proposal is BIP 360, which proposes witness version 2 for a quantum-resistant output type called P2MR (Pay-to-Merkle-Root). This design replaces Taproot's key-path spend (which is vulnerable to Shor's algorithm) with a pure script-tree commitment. For more context, see the research on post-quantum cryptography and Bitcoin.

Address Encoding

The witness version directly determines which address encoding a wallet uses. This mapping exists because of a subtle checksum weakness discovered in the original bech32 format.

Bech32 for Version 0

Bech32 (defined by BIP 173) encodes witness version 0 addresses. Mainnet addresses start with bc1q, where the q character represents version 0 in the bech32 character set. Testnet addresses use the prefix tb1q.

Bech32m for Version 1+

Bech32m (defined by BIP 350) encodes addresses for witness version 1 and all higher versions. The original bech32 format had a mutation weakness: inserting or deleting q characters before a final p could produce a valid checksum. While version 0 addresses caught this through fixed-length validation (20 or 32 bytes), future versions with variable-length programs would have been vulnerable.

Bech32m fixes this by changing a single constant in the checksum calculation from 1 to 0x2bc830a3. Everything else (character set, human-readable prefix, separator) remains identical. Taproot addresses start with bc1p, where p encodes version 1.

For a comprehensive overview of how these address types evolved, see the research article on Bitcoin address types from P2PKH to Taproot.

Why It Matters

The witness version system is one of Bitcoin's most important architectural decisions for long-term protocol evolution. Without it, every scripting upgrade would require complex workarounds or risk splitting the network.

Soft Fork Compatibility

The key insight is how old nodes handle unknown witness versions. When a pre-Taproot node encounters a version 1 output, it sees a scriptPubKey that pushes a number and some data onto the stack. Since the top stack element is non-zero, the script evaluates to TRUE: anyone can spend it. This means old nodes accept blocks containing new witness version outputs without rejecting them.

Upgraded nodes, meanwhile, enforce the stricter validation rules defined for that version. This is the textbook definition of a soft fork: new rules only tighten what is considered valid, never loosen it. Old nodes remain fully compatible, and the network upgrades without a chain split.

Clean Upgrade Path

With 15 unused witness versions remaining (2 through 16), Bitcoin has a clear runway for future upgrades. Each version can introduce entirely new signature schemes, script semantics, or spending policies. Potential uses include quantum-resistant cryptography, new covenant mechanisms, and advanced signature aggregation schemes.

Layer 2 protocols like the Lightning Network and Spark benefit directly from witness version upgrades. Taproot (version 1) enabled more efficient multisig constructions using MuSig2 and Schnorr signatures, reducing on-chain footprint for channel operations and improving privacy for cooperative closes.

Use Cases

• Protocol upgrades: each new witness version can activate an entirely new scripting system via soft fork. Taproot demonstrated this by introducing Schnorr signatures and Merkleized script trees under version 1.
• Wallet compatibility: wallets use the witness version to determine correct address encoding and transaction construction. Sending to a bc1q address requires different handling than a bc1p address.
• Future-proofing: by reserving versions 2 through 16, Bitcoin can adopt post-quantum cryptography, new covenant opcodes, or cross-input signature aggregation without protocol-level contortions.
• Layer 2 efficiency: newer witness versions enable more compact multisignature schemes and flexible spending conditions, directly benefiting off-chain protocols that rely on on-chain settlement transactions.

Risks and Considerations

Wallet Support Fragmentation

Each new witness version requires wallet software to update its address parsing, transaction building, and fee estimation logic. When Taproot launched, many wallets and exchanges could not initially send to bc1p addresses, causing user confusion and delayed adoption. This pattern will likely repeat with future witness versions.

Anyone-Can-Spend Window

Before a new witness version activates, outputs using that version are technically anyone-can-spend from the perspective of all nodes. A miner could theoretically steal these funds. In practice, standardness rules in Bitcoin Core's mempool policy reject transactions spending unknown witness versions, so they would not propagate through the network. However, this protection is policy-level, not consensus-level.

Version Space Exhaustion

Bitcoin has a fixed set of 17 witness versions (0 through 16), and two are already in use. While 15 remaining slots is generous by current standards, it is a finite resource. Each version must be allocated carefully, since there is no mechanism to add more witness versions without a hard fork or a meta-versioning scheme within an existing version.

Quantum Vulnerability of Existing Versions

Witness version 1 (Taproot) exposes the public key directly in the scriptPubKey. If large-scale quantum computers become practical, the key-path spending mechanism could be vulnerable to Shor's algorithm. This is one motivation behind BIP 360's proposed version 2, which would use hash-based commitments instead of exposed public keys. For a deeper analysis, see the research on Taproot's quantum vulnerability.

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.