Opcode

Opcode (operation code) is a single-byte instruction in Bitcoin Script, the stack-based language that defines how coins may be spent. Each opcode tells the script interpreter to perform one specific action on the stack — pushing data, duplicating or removing items, doing arithmetic or logical comparisons, hashing, or verifying signatures. Scripts are sequences of these opcodes, and complex spending conditions are built by composing many simple operations rather than writing free-form code. This minimalism is deliberate: a spending language that every node on earth must execute identically, forever, needs to be small enough to reason about exhaustively.

Categories of opcodes

Opcodes fall into broad groups. Data-pushing operations place bytes on the stack. Stack manipulation opcodes such as OP_DUP and OP_DROP rearrange it. Arithmetic and logic opcodes compare and compute. Cryptographic opcodes do the heavy lifting: OP_HASH160 hashes a public key for the classic pay-to-pubkey-hash pattern, while OP_CHECKSIG and OP_CHECKMULTISIG verify signatures against transaction data — the operations at the heart of every multisig wallet. Flow-control and timelock opcodes such as OP_IF, OP_CHECKLOCKTIMEVERIFY, and OP_CHECKSEQUENCEVERIFY enable conditional and time-delayed spending — the primitives underneath Lightning channels and inheritance schemes. A script succeeds if it runs to completion and leaves a true value on the stack; anything else, including executing a disabled opcode, fails the spend.

Disabled and proposed opcodes

Several opcodes present in Bitcoin's original design — including OP_CAT, which concatenates two stack items — were disabled early out of caution after bugs and denial-of-service concerns, and they are periodically revisited as candidates for re-enabling. New opcodes are also proposed to extend Script's capabilities, most prominently OP_CHECKTEMPLATEVERIFY and OP_VAULT for covenants, which would let a coin constrain where it can be spent, not just who can spend it. Adding or re-enabling an opcode is a consensus change requiring broad review and network-wide agreement, because every node must execute it identically — a single divergence forks the network. The Taproot upgrade showed the modern path: it introduced Tapscript, a revised script version that upgraded signature checking to Schnorr and reserved a clean upgrade mechanism (OP_SUCCESS opcodes) for future extensions.

Why the conservatism is the feature

For a sovereign user, the tiny opcode set is a guarantee, not a limitation. Every spending condition your coins can ever be bound by is drawn from a short, auditable menu that has been studied for over a decade. Expressive smart-contract languages trade that auditability for flexibility — and have paid for it repeatedly. Bitcoin's approach is the craftsman's: fewer tools, each one understood completely.

What a simple payment looks like in opcodes

The classic pay-to-pubkey-hash script shows how little is needed for real money. The locking script reads OP_DUP OP_HASH160 <pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG: duplicate the spender's supplied public key, hash it, check the hash matches the one the coins were locked to, then verify the signature. Five operations, executed identically by every node on earth, and the coins move — or they do not. Every fancier construction, from multisig vaults to Lightning channel scripts, is the same idea with more steps. Reading a script opcode by opcode is a skill worth an afternoon for any node runner: it converts "the wallet says it is locked" into an exact, verifiable statement of what unlocking requires. Block explorers and your own node's raw-transaction view will decode any script into its opcode sequence, which makes practicing on real transactions easy and free.

Opcodes are the atomic building blocks behind features like covenants and timelocks. See OP_CHECKTEMPLATEVERIFY (CTV) and the covenant entry for proposed extensions, and Bitcoin Script for the execution model they live in.