OP_NOP1 through OP_NOP10 - Upgrade Reserved Slots

15. OP_NOP1 through OP_NOP10 — Upgrade Reserved Slots

Overview

In addition to the base OP_NOP at 0x61, Bitcoin Script defines a range of NOP-like opcodes specifically reserved for future protocol upgrades. These are designated OP_NOP1 through OP_NOP10 and occupy bytes 0xb0 through 0xb9. Two of these slots have already been used for BIP-based soft forks.

The NOP Extension Range

OP_NOP1  = 0xb0  (available)
OP_NOP2  = 0xb1  --> repurposed as OP_CHECKLOCKTIMEVERIFY (BIP 65)
OP_NOP3  = 0xb2  --> repurposed as OP_CHECKSEQUENCEVERIFY (BIP 112)
OP_NOP4  = 0xb3  (available)
OP_NOP5  = 0xb4  (available)
OP_NOP6  = 0xb5  (available)
OP_NOP7  = 0xb6  (available)
OP_NOP8  = 0xb7  (available)
OP_NOP9  = 0xb8  (available)
OP_NOP10 = 0xb9  (available)

OP_NOP2 → OP_CHECKLOCKTIMEVERIFY

BIP 65 repurposed OP_NOP2 as OP_CHECKLOCKTIMEVERIFY (CLTV), activated in December 2015. The key insight is that redefining a NOP is backward compatible:

• Old nodes: see OP_NOP2, do nothing, script may succeed.

• New nodes: see OP_CHECKLOCKTIMEVERIFY, verify the lock time, fail if not satisfied.

CLTV script example (time-locked output):
<locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

Old node interpretation:
  <locktime>  --> pushed to stack
  OP_NOP2     --> does nothing
  OP_DROP     --> drops the locktime
  ... rest of P2PKH ...

New node interpretation:
  <locktime>  --> pushed to stack
  OP_CLTV     --> checks nLockTime >= locktime; fails if not
  OP_DROP     --> drops the locktime
  ... rest of P2PKH ...

OP_NOP3 → OP_CHECKSEQUENCEVERIFY

BIP 112 repurposed OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV), activated May 2016. It checks the relative lock time (using the sequence number field) instead of the absolute lock time.

CSV script example (relative time-lock):
<sequence_number> OP_CHECKSEQUENCEVERIFY OP_DROP
<pubkey> OP_CHECKSIG

This output cannot be spent until a minimum number of
blocks or time has elapsed since the UTXO was confirmed.

Remaining NOP Slots

Eight NOP slots (OP_NOP1, OP_NOP4 through OP_NOP10) remain available for future soft fork upgrades. Any future opcode needing a soft fork activation can be deployed by redefining one of these slots. The behavior before activation (doing nothing) ensures backward compatibility with nodes that have not upgraded.

// From src/script/interpreter.cpp
case OP_NOP1: case OP_NOP4: case OP_NOP5:
case OP_NOP6: case OP_NOP7: case OP_NOP8:
case OP_NOP9: case OP_NOP10: {
    if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS)
        return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
    break;
}

Note the SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS flag: standard Bitcoin Core nodes discourage (but do not reject) transactions that use unassigned NOP slots, by returning an error in policy mode. This prevents users from accidentally "using" reserved upgrade slots for non-standard purposes.