Script Version and Upgrade Mechanisms

Bitcoin Script has evolved significantly since 2009. New opcodes have been added, bugs have been fixed, and entirely new script types have been introduced. All of these changes were deployed as soft forks — backward-compatible upgrades that did not invalidate old transactions.

The Core Challenge: Upgrading Without Breaking

Bitcoin is a consensus system. Every full node in the network must agree on which transactions are valid. If you want to add a new script feature, you face a dilemma:

• Old nodes that don't know about the new feature might reject valid new transactions

• New nodes that enforce the new rules might accept transactions that old nodes don't understand

Soft forks solve this by making new rules more restrictive than old rules. Old nodes see the new transactions as valid (under old rules), while new nodes enforce additional constraints. The network converges on the stricter set of rules as more nodes upgrade.

Mechanism 1: OP_NOP Repurposing

The simplest upgrade mechanism is repurposing OP_NOP opcodes. The Script specification defines OP_NOP1 through OP_NOP10. These opcodes do nothing — they are no-ops.

Old nodes see them and continue execution unchanged. New nodes can redefine these no-ops to perform real operations — but crucially, the new operations must only pass or fail, never push new data that would change the stack for old nodes.

This is how OP_CHECKLOCKTIMEVERIFY (CLTV) was deployed. It repurposed OP_NOP2:

Old nodes see: OP_NOP2     → do nothing, continue
New nodes see: OP_CLTV     → check timelock, fail if invalid

If CLTV passes (timelock satisfied), execution continues — same as OP_NOP did. If it fails, the transaction is invalid — also safe, since old nodes were never going to reject it (they saw a NOP).

Mechanism 2: P2SH Envelope

Pay-to-Script-Hash (BIP 16, 2012) introduced a generic envelope for new script types. The P2SH locking script is:

OP_HASH160 <20-byte-hash> OP_EQUAL

Old nodes see this as a simple hash equality check. New nodes know to deserialize the last item pushed by the scriptSig as a "redeem script" and execute it separately.

P2SH unlocked the ability to deploy new script types without requiring any changes to the locking script format. New spending conditions can be encoded in the redeem script and hidden behind the hash until spend time.

Mechanism 3: SegWit Witness Versioning

SegWit (BIP 141, 2017) introduced a clean versioning system for future script upgrades. A SegWit output begins with:

<version byte (0–16)> <witness program (2–40 bytes)>

Currently:

• Version 0: P2WPKH (20-byte program) or P2WSH (32-byte program)

• Version 1: P2TR (Taproot, 32-byte x-only pubkey)

• Versions 2–16: Reserved for future use

Old nodes (before SegWit) see version 0 and version 1 outputs as "anyone can spend" (because the script just pushes a version number and data — which is truthy). New nodes enforce the full SegWit rules. This is the soft fork mechanism.

// SegWit v0 P2WPKH:
OP_0 <20-byte-hash>

// SegWit v1 P2TR:
OP_1 <32-byte-x-only-pubkey>

// Future SegWit v2 (hypothetical):
OP_2 <witness-program>

Mechanism 4: Tapscript OP_SUCCESS

Within Tapscript (the script language used in Taproot script paths), a new upgrade mechanism was introduced: OP_SUCCESS opcodes.

Any opcode in the range 0x50, 0x62, 0x89, 0x8a, 0x96–0x9f, 0xa8, 0xab–0xaf, and others are defined as OP_SUCCESS in Tapscript. When a Tapscript interpreter encounters one, the entire script succeeds immediately regardless of stack state.

This allows new opcodes to be introduced by redefining current OP_SUCCESS values. Old nodes see OP_SUCCESS and the script passes (they accept it). New nodes enforce the new opcode's real semantics. Since the new opcode can be more restrictive than "always succeed," this is a valid soft fork mechanism.