Q&A: How do OP codes fit into a bitcoin cash transaction?

• How Opcodes Fit Into a Bitcoin Cash Transaction
  • 1. Where scripts (and therefore opcodes) live
  • 2. How opcodes are structured
  • 3. How they execute
  • 4. Worked example: P2PKH
  • 5. Bitcoin Cash’s opcode evolution
  • 6. Two important caveats

Question:

How do OP codes fit into a bitcoin cash transaction?

Answer:

§How Opcodes Fit Into a Bitcoin Cash Transaction

Short answer: An opcode (“operation code”) is the single-byte instruction that makes up a transaction’s scripts. A Bitcoin Cash transaction doesn’t carry opcodes as a separate field — opcodes are the bytecode inside each input’s unlocking script and each output’s locking script. When a node validates a spend, it runs those scripts through a stack-based virtual machine, and the opcodes are the commands that VM executes.

§1. Where scripts (and therefore opcodes) live

A BCH transaction has two script-bearing fields:

Every output’s locking script sets the rules; a later transaction’s input provides an unlocking script that must satisfy them. (Source: PSF wiki transaction-scripts.md, locking-script.md.)

§2. How opcodes are structured

A script is just a byte string. Each byte is interpreted as either:

• A data push — e.g. small constants OP_0/OP_1…OP_16, or OP_PUSHDATA/OP_DATA_X followed by raw bytes (a public key, signature, or hash), or
• An operation — e.g. OP_DUP, OP_HASH160, OP_EQUALVERIFY, OP_CHECKSIG, OP_ADD, OP_RETURN.

The language is Forth-like, stack-based, non-Turing-complete, stateless, and has no loops — a deliberate design choice to prevent infinite loops from crashing nodes (Source: transaction-script-language.md).

§3. How they execute

1. The unlocking script runs first, pushing values onto the stack.
2. Then the locking script runs against that stack (this ordering prevents an unlocking script from simply wiping the stack and returning “true”).
3. If the top stack item is true (non-zero) at the end, the input is spendable. (Source: locking-script.md.)

§4. Worked example: P2PKH

The most common transaction type:

• Locking script: OP_DUP OP_HASH160 <20-byte pubkey hash> OP_EQUALVERIFY OP_CHECKSIG
• Unlocking script: <signature> <public key>

Execution: unlocking pushes signature + pubkey → OP_DUP duplicates the pubkey → OP_HASH160 hashes it → <hash> pushes the expected address → OP_EQUALVERIFY checks they match (else fail) → OP_CHECKSIG verifies the signature against the pubkey. Result true = spendable. (Source: locking-script.md.)

Other standard patterns use opcodes the same way: P2SH (OP_HASH160 <hash> OP_EQUAL plus a redeem script), bare multisig (OP_CHECKMULTISIG), and OP_RETURN outputs (immediately fail, making them provably unspendable data carriers) (Source: standard-transaction-types.md).

§5. Bitcoin Cash’s opcode evolution

BCH has actively extended its opcode set beyond BTC’s:

• May 2018: Re-enabled the opcodes Bitcoin disabled in 2010–2011 (OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_NUM2BIN, etc.), removed the 201-op limit, and raised the stack-element/script size limit to 10,000 bytes. (Sources: upgradespecs.bitcoincashnode.org, bch-vm-limits.)
• November 2018: Added OP_CHECKDATASIG/OP_CHECKDATASIGVERIFY (signature checks on arbitrary data, not just the transaction).
• May 2020: Added OP_REVERSEBYTES (opcode 188 / 0xbc). (Source: documentation.cash.)
• May 2022 (introspection): Added native introspection opcodes (e.g. OP_INPUTINDEX, OP_UTXOVALUE, OP_OUTPUTBYTECODE) letting scripts inspect transaction data.
• May 2023 (CashTokens): Added six token-inspection opcodes at codepoints 0xce–0xd3 (OP_UTXOTOKENCATEGORY, OP_UTXOTOKENCOMMITMENT, OP_UTXOTOKENAMOUNT, and their OP_OUTPUT… counterparts). (Source: cashtokens-spec.md.)

§6. Two important caveats

• Consensus vs. standardness: Opcode rules are consensus-critical (a bad opcode = invalid block), but which patterns nodes relay is a separate “standardness” policy. Non-standard scripts can still be mined.
• Token prefixes aren’t opcodes: In CashTokens, token data is encoded in a prefix (0xef) before the locking bytecode — it’s data, not part of the executed opcode stream (Source: cashtokens-spec.md).

In one line: opcodes are the individual instructions inside the unlocking and locking scripts attached to transaction inputs and outputs; the BCH VM runs them on a stack to decide whether an output may be spent.

Sources: PSF LLM Wiki (transaction-scripts.md, locking-script.md, transaction-script-language.md, transaction-anatomy.md, standard-transaction-types.md, cashtokens-spec.md) and documentation.cash / upgradespecs.bitcoincashnode.org.

Public Q&A mirror from the Block tech-support bot.