Opcode

Anna wants to pay Peter. Her wallet prepares a transaction and the necessary signatures; nodes then check whether she was allowed to use the selected coins. A wallet is an application or device for receiving and sending bitcoin. A node is software that checks transactions and blocks and communicates with other participants in the network. Bitcoin Script is the language behind part of that checking. An opcode is one instruction, such as checking a signature. Anna does not write instructions by hand for an ordinary payment. But a node cannot trust an owner’s name or a label saying “signed”: it must evaluate the relevant conditions. A valid script is only part of validating the whole transaction. [1] [4]

A readable listing may show OP_DUP or OP_CHECKSIG. These are human-readable instruction names, represented by single-byte codes in the script. A byte is a standard unit of data size. Other parts contain data, such as a public key. A public key is used to verify signatures and does not need to be kept secret. Instructions in the OP_PUSHDATA family specify how many following bytes to insert as data. Bytes inside that inserted data are not executed again as instructions. Think of the difference between “add salt” in a recipe and the ingredient put into the bowl. [1] [2]

Imagine a pile of notes from which you take the top item. That is how the script’s basic working stack behaves. OP_DUP copies the top item; OP_DROP removes it. Executing OP_DUP and then OP_DROP on a non-empty stack returns it to its original contents. You have not duplicated coins, only working data. Evaluation can fail if a required item is missing. The order and exact encoding of the items matter too. [1]

OP_EQUAL takes the top two items, compares their bytes and replaces them with the equality result. OP_EQUALVERIFY immediately fails if they differ; if they match, it continues without that result on the stack. Neither operation checks a signature by itself. Anyone can supply two identical copies of a public key. An appropriate signature check is needed to establish that someone could sign the required message. [1] [4]

OP_CHECKSIG verifies a signature against a public key and a message assembled from the transaction. A private key is a secret numerical value used to create such a signature. Verifying the signature does not reveal the private key. The sighash setting determines which transaction parts the signature covers; not every mode promises to sign everything. Older scripts and SegWit version 0 use ECDSA, one signature algorithm. Tapscript, the script rules for Taproot, uses Schnorr, another algorithm, for ordinary 32-byte keys. An instruction’s name is not enough without this context. [1] [3]

A condition can allow normal spending or an alternative recovery path. OP_IF and OP_ELSE help choose a branch using a stack value; OP_ENDIF closes the conditional section. Bitcoin Script has no general programming loops that can repeat arbitrarily. That does not mean everything in an unexecuted branch can be ignored. Some instructions are checked while reading the script; their type and the rule version matter. [1] [3]

CLTV, the OP_CHECKLOCKTIMEVERIFY instruction, can enforce an absolute threshold, for example a specified block height, the block’s position in the chain. CSV, OP_CHECKSEQUENCEVERIFY, works with transaction-age rules to enforce a relative delay from confirmation of the output being spent. An output is a previously received amount with spending conditions. These instructions check transaction fields; they do not start a timer, send money or replace a signature. A particular application must combine the right time lock with its other conditions. [7] [8] [9]

Before reading a technical example, establish whether it uses older scripts, SegWit or Tapscript. Tapscript adds OP_CHECKSIGADD to combine signature checks. Conversely, OP_CHECKMULTISIG fails when executed; its rules ignore it in an unexecuted branch. The names are not contradictory: the verification environments differ. An opcode list is not a universal set of building blocks that can be moved between formats without further thought. [1] [3] [6]

BIP 342 reserves the OP_SUCCESSx family for future Tapscript extensions. After the preceding checks pass, encountering one while decoding skips the subsequent script checks with success, even in an unexecuted branch. A coincidentally equal byte inside pushed data does not count. This leaves room for rule changes; it is not a new protection already activated. A condition relying on an undefined future meaning may fail to protect funds as its author expects. [1] [3]

A Full Node independently checks validity rules, but can apply stricter rules to accepting and sharing unconfirmed transactions. By default, Bitcoin Core v29.0 refuses to relay transactions using an OP_SUCCESSx instruction in Tapscript, even though consensus may permit them in a block. The reader’s approach is straightforward: identify the version, initial data, signature coverage and failure cases. Readable syntax alone is not proof of a secure wallet; in ordinary use you rely on reviewed software to do this work. [1] [5]