Bitcoin Script Opcode Reference Guide

Bitcoin Script Opcodes Overview

Bitcoin Script is a stack-based, non-Turing-complete programming language that defines spending conditions for every UTXO on the Bitcoin network. Each instruction in Bitcoin Script is called an opcode: a single byte (0x00 through 0xff) that tells the interpreter what operation to perform on the stack. The total opcode space is 256 values, of which approximately 116 are currently active.

This reference covers every major opcode category, provides hex values for commonly used opcodes, documents standard script patterns from P2PKH through Taproot, and tracks proposed additions. For hands-on script analysis, use the Bitcoin Script debugger.

Constants and Push Operations

Constant opcodes push data onto the stack. Bytes 0x01 through 0x4b push the next N bytes directly (where N equals the opcode value). OP_PUSHDATA1, OP_PUSHDATA2, and OP_PUSHDATA4 handle larger payloads using a length prefix. The number opcodes OP_0 through OP_16 push small integer values and appear in nearly every standard script.

Flow Control

Flow control opcodes enable conditional execution within scripts. They are essential for constructing HTLCs, timelocked spending paths, and other branching logic. Bitcoin Script has no loops: OP_IF / OP_ELSE / OP_ENDIF provide the only branching mechanism, keeping execution bounded.

Stack Operations

Stack opcodes manipulate items on the main stack and the alternate stack. Since Bitcoin Script is entirely stack-based, these operations are fundamental: OP_DUP alone appears in billions of P2PKH outputs across the blockchain.

Arithmetic Operations

Arithmetic opcodes operate on signed integers in little-endian format, limited to 4 bytes (values from -2,147,483,647 to 2,147,483,647). Inputs larger than 4 bytes cause immediate script failure. Several arithmetic opcodes (multiplication, division, modulo, bit shifts) were disabled in 2010 due to implementation bugs.

Cryptographic and Hashing Opcodes

Cryptographic opcodes are the backbone of Bitcoin's spending conditions. Every standard transaction uses at least one hashing opcode and one signature-checking opcode. OP_HASH160 (SHA-256 followed by RIPEMD-160) produces the 20-byte hashes used in P2PKH and P2SH addresses. OP_CHECKSIG verifies ECDSA signatures against the spending transaction.

OP_CHECKMULTISIG has a well-known off-by-one bug: it consumes one extra unused stack element beyond what is needed. Standard transactions place a dummy OP_0 in this position. Tapscript (BIP 342) replaced OP_CHECKMULTISIG with OP_CHECKSIGADD, which uses Schnorr signatures and eliminates the off-by-one issue entirely.

Locktime Opcodes

Timelock opcodes enforce time-based spending restrictions directly in Script. They are critical for Lightning channels, HTLCs, and covenant constructions. Both opcodes were introduced as soft forks by redefining previously unused NOP opcodes.

CLTV enables absolute deadlines: "this output cannot be spent before block 900,000." CSV enables relative delays: "this output cannot be spent until 144 blocks after confirmation." Together, they power the penalty and revocation mechanisms in Lightning Network channels. For a deeper technical treatment, see our research on Bitcoin timelocks: CLTV and CSV. You can also decode timelock values with the timelock decoder.

Common Script Patterns

Standard transaction types combine opcodes into well-known patterns. Each pattern corresponds to a specific Bitcoin address type. The following table summarizes the five standard script types used on the Bitcoin network.

P2PKH Execution Flow

P2PKH (Pay-to-Public-Key-Hash) is the original standard transaction type. To spend a P2PKH output, the spender provides a signature and public key in the scriptSig. The script executes as follows:

1. OP_DUP duplicates the public key on the stack
2. OP_HASH160 hashes the duplicate (SHA-256 then RIPEMD-160)
3. The 20-byte hash from the scriptPubKey is pushed onto the stack
4. OP_EQUALVERIFY checks the two hashes match
5. OP_CHECKSIG verifies the signature against the original public key and the transaction data

P2SH and Nested Scripts

P2SH (Pay-to-Script-Hash, BIP 16) hashes an arbitrary script into a 20-byte value embedded in the output. The spender provides the full redeem script at spend time. This is the foundation for multisig wallets and wrapped SegWit addresses. The node hashes the provided redeem script with OP_HASH160, compares it to the embedded hash, then deserializes and executes the redeem script.

P2WPKH and SegWit v0

P2WPKH (BIP 141) moves signature data to the witness field, reducing transaction weight by roughly 40% compared to equivalent P2PKH transactions. The scriptPubKey contains only OP_0 followed by a 20-byte public key hash. The scriptSig must be empty: the signature and compressed public key appear exclusively in the witness. For details on how this affects transaction structure, see our transaction lifecycle guide.

P2TR and Taproot

Taproot (BIP 341/342) introduced SegWit v1 outputs, identified by OP_1 followed by a 32-byte tweaked public key. Taproot supports two spend paths: a key path spend using a single Schnorr signature, or a script path spend that reveals a leaf script from a Merkle tree. Tapscript (BIP 342) replaces OP_CHECKMULTISIG with OP_CHECKSIGADD and uses 32-byte x-only public keys. For a comprehensive overview, see our research on Taproot and Schnorr signatures.

Disabled Opcodes

In 2010, Satoshi Nakamoto disabled 15 opcodes in a single commit after discovering that OP_LSHIFT contained a crash vulnerability that could take down any Bitcoin node. The remaining opcodes were removed as a precaution against similar undiscovered bugs. These opcodes cause immediate script failure if encountered in any transaction:

• Splice operations: OP_CAT (0x7e), OP_SUBSTR (0x7f), OP_LEFT (0x80), OP_RIGHT (0x81)
• Bitwise logic: OP_INVERT (0x83), OP_AND (0x84), OP_OR (0x85), OP_XOR (0x86)
• Arithmetic: OP_MUL (0x95), OP_DIV (0x96), OP_MOD (0x97), OP_2MUL (0x8d), OP_2DIV (0x8e), OP_LSHIFT (0x98), OP_RSHIFT (0x99)

Proposed Opcodes

Several opcode proposals are in various stages of development. These would expand Bitcoin Script's programmability while maintaining the language's security properties. All proposals target Tapscript only: they would not affect legacy or SegWit v0 scripts.

OP_CHECKTEMPLATEVERIFY (BIP 119)

CTV would redefine OP_NOP4 (0xb3). It pops a 32-byte hash from the stack and verifies that the spending transaction matches a commitment covering its version, locktime, outputs, and input index. This enables non-interactive covenants, vaults, and congestion control batching. CTV has significant developer support but no confirmed activation timeline as of mid-2026.

OP_CAT Reactivation (BIP 347)

BIP 347 would reactivate OP_CAT in Tapscript only, redefining OP_SUCCESS126 (0x7e). The reactivated version concatenates two stack elements with a 520-byte result limit, preventing the unbounded memory issues that led to its original removal. BIP 347 was marked specification-complete in March 2026 but still requires a separate soft fork activation.

OP_CHECKSIGFROMSTACK (BIP 348)

CSFS would verify Schnorr signatures against arbitrary messages (not just the transaction hash). Combined with CTV, this enables LN-Symmetry channels, oracle-based contracts, and Discreet Log Contracts. The specification was merged in December 2024 and is available for testing on signet.

Quick Hex Reference

The most frequently encountered opcodes in raw transaction data, with their hex byte values:

Use the transaction decoder to see these opcodes in real Bitcoin transactions, or the Script debugger to step through execution interactively.

Frequently Asked Questions

How many opcodes does Bitcoin Script have?

Bitcoin Script's opcode space is 256 values (one byte each, 0x00 through 0xff). Approximately 116 are currently active. Fifteen were disabled in 2010 due to implementation bugs. The remaining values are reserved, undefined, or (in Tapscript) allocated as OP_SUCCESSx slots for future soft fork upgrades.

Why were opcodes like OP_CAT and OP_MUL disabled?

Satoshi Nakamoto disabled 15 opcodes in 2010 after discovering that OP_LSHIFT contained a crash vulnerability that could bring down any Bitcoin node. The other splice, bitwise, and arithmetic opcodes were removed simultaneously as a precaution against similar undiscovered bugs. BIP 347 proposes reactivating OP_CAT in Tapscript only, with a 520-byte concatenation limit to prevent the memory issues that motivated its original removal.

What is the difference between OP_CHECKSIG and OP_CHECKMULTISIG?

OP_CHECKSIG verifies a single signature against a single public key. OP_CHECKMULTISIG verifies M valid signatures from a set of N public keys (M-of-N). OP_CHECKMULTISIG has a known off-by-one bug requiring a dummy OP_0 on the stack. In Tapscript (BIP 342), OP_CHECKMULTISIG is replaced by OP_CHECKSIGADD, which checks signatures incrementally using Schnorr signatures and eliminates the off-by-one issue.

What is the difference between OP_HASH160 and OP_SHA256?

OP_SHA256 performs a single SHA-256 hash, producing a 32-byte output. OP_HASH160 applies SHA-256 followed by RIPEMD-160, producing a 20-byte output. OP_HASH160 is used in P2PKH and P2SH scripts to create the shorter hashes embedded in legacy Bitcoin addresses. P2WSH uses a single SHA-256 hash (not HASH160) for its 32-byte script hash.

How do OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY differ?

OP_CHECKLOCKTIMEVERIFY (CLTV, BIP 65) enforces absolute time locks: the transaction cannot be mined before a specific block height or Unix timestamp. OP_CHECKSEQUENCEVERIFY (CSV, BIP 112) enforces relative time locks: the input cannot be spent until a certain number of blocks or seconds have elapsed since the UTXO was confirmed. CSV is essential for Lightning channel penalty mechanisms. For more detail, see our timelocks research.

What opcodes does a P2PKH transaction use?

A P2PKH scriptPubKey uses five opcodes: OP_DUP (0x76), OP_HASH160 (0xa9), a 20-byte push of the public key hash, OP_EQUALVERIFY (0x88), and OP_CHECKSIG (0xac). The hex pattern in raw transactions is always 76 a9 14 [20 bytes] 88 ac. This pattern can be identified in any block explorer or with the transaction decoder.

What is OP_RETURN used for?

OP_RETURN (0x6a) marks a transaction output as provably unspendable, allowing arbitrary data to be embedded in the blockchain without bloating the UTXO set. Common uses include timestamping documents, anchoring sidechain data, and encoding metadata for protocols like Ordinals and Runes. Bitcoin Core nodes relay OP_RETURN outputs containing up to 80 bytes of data by default. See our OP_RETURN decoder to inspect embedded data in real transactions.

This reference is for informational purposes only and does not constitute financial or technical advice. Opcode behavior is defined by the Bitcoin Core reference implementation and may change through consensus upgrades. Always verify opcode specifications against the current Bitcoin Core source code before building production applications.