OP_1 through OP_16 - Pushing Small Integers

2. OP_1 through OP_16 — Pushing Small Integers

Overview

Bitcoin Script provides a dedicated set of opcodes for pushing the small integers 1 through 16 onto the stack. These opcodes run from OP_1 (also called OP_TRUE) through OP_16 and occupy byte values 0x51 through 0x60 in the opcode space. They are single-byte instructions that do not require any additional data bytes in the script — the value to be pushed is implicit in the opcode itself.

Opcode Byte Values

OP_1  = 0x51   (also OP_TRUE)
OP_2  = 0x52
OP_3  = 0x53
OP_4  = 0x54
OP_5  = 0x55
OP_6  = 0x56
OP_7  = 0x57
OP_8  = 0x58
OP_9  = 0x59
OP_10 = 0x5a
OP_11 = 0x5b
OP_12 = 0x5c
OP_13 = 0x5d
OP_14 = 0x5e
OP_15 = 0x5f
OP_16 = 0x60

What Gets Pushed

When OP_N executes, it pushes the Script-encoded representation of the integer N onto the stack. For integers 1 through 16, the Script number encoding is simply a single byte equal to the value:

OP_1  pushes: [0x01]
OP_2  pushes: [0x02]
OP_3  pushes: [0x03]
...
OP_16 pushes: [0x10]

The interpreter encodes the number using the minimal Script number format. For values 1–127, this is just one byte. These pushed values can then be consumed by arithmetic opcodes or used as arguments to opcodes like OP_CHECKMULTISIG.

OP_1 as OP_TRUE

OP_1 is aliased as OP_TRUE because [0x01] evaluates to true in boolean context. It is often used in test scripts or pay-to-anyone outputs:

Simplest spendable output (pay to anyone):
scriptPubKey: OP_TRUE
Hex: 0x51

This output can be spent with an empty scriptSig.

Multisig Threshold Specification

The most common real-world usage of OP_1 through OP_16 is specifying the M-of-N thresholds in multisignature scripts. The OP_CHECKMULTISIG opcode reads two numbers from the stack: first N (total keys), then M (required signatures). These are typically pushed using small-integer opcodes:

1-of-1 multisig:
OP_1 <pubkey> OP_1 OP_CHECKMULTISIG

2-of-3 multisig:
OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

3-of-5 multisig:
OP_3 <pk1> <pk2> <pk3> <pk4> <pk5> OP_5 OP_CHECKMULTISIG

Maximum standard multisig (15-of-15):
OP_15 <pk1>...<pk15> OP_15 OP_CHECKMULTISIG

Bitcoin limits standard (non-SegWit) multisig to 3-of-3 via standardness rules enforced by Bitcoin Core's mempool policy. However, the opcode space technically supports up to 20 keys.

Taproot Version Marker

With the activation of Taproot (BIP 341) in November 2021, OP_1 gained a new significance as the witness program version marker for P2TR (Pay-to-Taproot) outputs:

P2TR scriptPubKey:
OP_1 <32-byte-x-only-pubkey>
Hex: 0x51 0x20 <32 bytes>

Future SegWit versions will use OP_2 through OP_16 as version markers, enabling additional upgrade paths while maintaining backward compatibility with non-upgraded nodes.

Bitcoin Core Implementation

// From src/script/interpreter.cpp
case OP_1:
case OP_2:
// ... through OP_16
{
    // The number n is encoded as: opcode - (OP_1 - 1)
    int n = (int)opcode - (int)(OP_1 - 1);
    stack.push_back(CScriptNum::serialize(n));
    break;
}

The formula opcode - (OP_1 - 1) maps 0x51 → 1, 0x52 → 2, and so on through 0x60 → 16.

Efficiency Advantage

Using OP_1 through OP_16 is more byte-efficient than using a direct push opcode followed by the value byte. A direct push of 0x01 requires two bytes (push length + data), whereas OP_1 requires only one. This is why BIP 62 (Minimal Push Rules) mandates the use of these small-integer opcodes rather than direct pushes when the value falls in their range.

Inefficient (non-minimal) push of integer 2:
0x01 0x02    (2 bytes: push-1-byte opcode, then value 2)

Efficient (minimal) push of integer 2:
0x52         (1 byte: OP_2)