Bitcoin Script

Alice receives 20 000 sat, twenty thousand of bitcoin’s smallest units. The network does not create an account in her name. It creates a transaction output: an amount and a condition for spending it later. Until spent, this is called a UTXO. In a common payment, the condition requires a signature from the matching key. When Alice later pays someone, her wallet selects this output, references it through a new transaction input, and creates a digital signature. It uses her private key without sending that key anywhere; others verify the signature using the public key. Knowing Alice’s receiving address is not enough. The original output’s conditions are recorded in a field called scriptPubKey, and Bitcoin Script specifies how to check that they have been met. A node is not an official who recognizes Alice: it is a computer checking rules. Besides checking the signature, it must also establish, for example, that the same output has not already been spent. A transaction is valid only when all applicable rules are satisfied. [4] [2]

For ordinary payments, your wallet constructs the conditions. Follow its backup instructions; a normal recovery from words into a compatible wallet does not automatically require saving every script by hand. In a more complex setup, such as Multisig requiring several signatures, one participant’s words may not describe the complete spending arrangement. For everyday use, a wallet with tested procedures is preferable to assembling scripts manually in hexadecimal. Output descriptors describe the script type, keys, and their derivation, helping determine what a restored wallet should look for. A private key alone may not be enough to restore a more complex setup. Also preserve the required scripts and key origin information—where and how the keys were derived—and verify the intended spending paths. [11]

The following chapters examine how conditions are encoded inside a transaction; you do not need to know this to make everyday payments. The scriptSig field and the part called witness supply validation data. A hash is a fingerprint of data, and a timelock prevents spending before a specified threshold. Think of a stack as a pile of items worked on from the top. Script processes data using a stack: values are pushed onto it, and instructions called opcodes remove, compare, or otherwise process them. Signature instructions verify signatures; private keys and signature creation are not part of this validation. The language can combine signatures, hash conditions, and timelocks. It has no general-purpose loops and is not Turing-complete: it cannot express every computation that a general-purpose programming language can. The node must apply the precise rules for the output type and script version concerned. [1] [3]

A P2PKH (Pay to Public Key Hash) output normally takes the form OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. The input supplies a signature and a public key in its scriptSig. Validation checks that the public key’s hash matches the value in the output, then verifies the signature. Knowing the address or public key alone is therefore insufficient to spend such an output. The private key is used by the signing wallet, not by the node checking the transaction. [1]

P2SH stores a script hash in the output under BIP16. The spending input provides the matching redeemScript—the script revealed when spending—along with the necessary data. Its scriptSig may contain only instructions that push data. The node first checks that the hash matches, then evaluates redeemScript using the remaining stack items. A correct hash alone is insufficient to spend the output: the script’s conditions must also be satisfied. [5]

With SegWit version 0, validation data moves into the part of the transaction called the witness. This is a list of data items, not itself a script. P2WPKH uses a signature and a public key; P2WSH also includes a witnessScript whose SHA256 hash must match the output. For native SegWit, scriptSig is empty. When wrapped in P2SH, it contains only a push of the corresponding witness program; the actual validation data remains in the witness. [6]

Signature verification uses a message derived from the transaction according to a defined procedure. The SIGHASH mode determines which parts the signature protects against modification. It is therefore incorrect to assume that every signature covers the entire transaction. BIP143 always includes the amount of the output being spent for signature operations in SegWit version 0. The wallet must know the correct data and the selected mode; Script does not assess the signer’s human intentions during validation. [7]

Under BIP341, Taproot allows a P2TR (Pay to Taproot) output to be spent in two ways. The key path verifies a Schnorr signature against the output public key without revealing a script. The script path instead reveals the selected script and a control block that proves the output commits to that script. The other scripts in the tree need not be revealed. The rules for the revealed script also depend on the version of its leaf. [8]

BIP342 defines Tapscript for Taproot leaves of version 0xc0. Signature instructions here use Schnorr signatures, and OP_CHECKSIGADD can be used to construct a condition requiring multiple signatures. Executing the old OP_CHECKMULTISIG opcode causes validation to fail. The previous script length limit of 10 000 bytes and the limit of 201 opcodes counted under the older rules do not apply. A budget derived from witness size limits signature operations; stack limits still exist. The limits of one version must therefore not be presented as general properties of all Script. [9]

Consensus rules determine whether a spend is valid in a block. Standardness refers to additional local node rules for accepting unconfirmed transactions into the Mempool and relaying them; it is not a standardization process. A consensus-valid transaction may therefore not be widely relayed. OP_SUCCESSx in Tapscript requires particular care: after the preceding checks have passed, encountering it during decoding makes script validation succeed before normal execution and stack checks. It provides room for future extensions rather than an ordinary safe spending condition. [10] [9]