128 / 691OP

Bitcoin Script opcode

An opcode is a Bitcoin Script instruction. When a spend is verified it manipulates the stack or checks a condition; its meaning also depends on the script version.

An opcode is an instruction byte, not a private key or a standalone transaction. A successful spend requires a valid complete script and transaction context, not merely an operation name.

Script is decoded into instructions and data items. OP_PUSHDATA specifies pushing bytes; bytes inside pushed data are not reinterpreted as further opcodes. [Bitcoin Core v29.0 — Script interpreter] [Bitcoin Core v29.0 — Opcode definitions]

OP_DUP duplicates the stack top and OP_DROP removes it. A missing argument can cause failure; item order and encoding are part of the condition. [Bitcoin Core v29.0 — Script interpreter] [Bitcoin Developer Guide — Transactions]

OP_EQUAL compares two items and pushes the result. OP_EQUALVERIFY fails on inequality and removes the result on equality; neither operation alone verifies control of a key. [Bitcoin Core v29.0 — Script interpreter] [Bitcoin Core v29.0 — Opcode definitions]

OP_CHECKSIG verifies a signature against a public key and a transaction-derived message. Legacy and SegWit v0 use ECDSA; ordinary 32-byte Tapscript keys use Schnorr. The sighash also determines the commitment scope. [Bitcoin Core v29.0 — Script interpreter] [BIP 342 — Validation of Taproot Scripts]

OP_IF and OP_ELSE select a branch using the stack. Script has no general loops; rules for unexecuted branches still depend on opcode type and script version. [Bitcoin Core v29.0 — Script interpreter] [BIP 342 — Validation of Taproot Scripts]

OP_CHECKLOCKTIMEVERIFY checks an absolute lock and OP_CHECKSEQUENCEVERIFY a relative condition for the relevant input. They do not wait, send a payment or replace a signature condition. [Bitcoin Core v29.0 — Script interpreter] [Bitcoin Developer Guide — Transactions]

Tapscript changes signature rules, adds OP_CHECKSIGADD and rejects OP_CHECKMULTISIG when executed. An instruction list without a version is therefore not a complete validation guide. [BIP 342 — Validation of Taproot Scripts]

BIP 342 reserves OP_SUCCESSx for future extensions: encountering one while decoding Tapscript allows success under those rules. This does not mean a proposed operation is already activated or safely enforces the intended condition. [BIP 342 — Validation of Taproot Scripts] [Bitcoin Core — Segregated Witness benefits]

Network policy may refuse to relay a transaction that consensus permits in a block. Bitcoin Core v29.0, for example, discourages OP_SUCCESSx by default; node policy is not a new consensus rule. [BIP 342 — Validation of Taproot Scripts] [Bitcoin Core v29.0 — Standard script flags]

When reading a script, identify its version, initial stack, signature message and all failure paths. Valid syntax or an appealing opcode name does not guarantee correct custody; the complete use matters. [Bitcoin Core v29.0 — Script interpreter] [Bitcoin Developer Guide — Transactions]

For the clearest picture, read this entry together with Bitcoin Script, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, Taproot.

DOC · 001Bitcoin Core v29.0 — Script interpreterDocumentationDOC · 002Bitcoin Core v29.0 — Opcode definitionsDocumentationDOC · 003BIP 342 — Validation of Taproot ScriptsSpecificationDOC · 004Bitcoin Developer Guide — TransactionsDocumentationDOC · 005Bitcoin Core v29.0 — Standard script flagsDocumentationDOC · 006Bitcoin Core — Segregated Witness benefitsDocumentation
Source-first · No investment advice