Understanding bitcoin transaction input and output scripts requires examining the dual-program mechanism that enforces spending conditions across the network. An output script defines cryptographic challenges that lock a value, while an input script provides the unlocking parameters. Together, these stack-based bytecodes execute sequentially to determine whether an attempt to consume an unspent output is valid.
Anatomy of locking and unlocking scripts
Every standard transaction output contains a quantity of satoshis and a locking bytecode sequence referred to as the scriptPubKey. This script explicitly states the requirements that must be met to spend the allocated funds. Requirements frequently demand a cryptographic signature corresponding to a specific public key, but they can also enforce multivariable logic, hash preimages, or relative delays.
When a transaction attempts to spend an existing output, its input must supply an unlocking script, historically known as the scriptSig. In transactions utilizing segregated witness structures, this unlocking material may instead reside partially or entirely within a distinct witness field. Regardless of location, the unlocking data provides the cryptographic arguments—such as signatures and public keys—required to satisfy the encumbrance recorded in the referenced output.
Because the network operates on an unspent transaction output model rather than an account balance ledger, validating ownership requires executing these two scripts in tandem for each spent input. An input script cannot modify the output script it attempts to spend; it merely supplies the necessary inputs to satisfy it.
The stack execution model
Script interpretation relies on a minimalistic, non-Turing-complete language executed on a last-in, first-out data stack. The language lacks loops and complex branching to prevent state bloat and infinite execution attacks, ensuring deterministic runtime across all nodes.
The virtual machine reads operational codes and data pushes from left to right. When the interpreter encounters a data payload, it pushes those raw bytes onto the stack. When it encounters an opcode, it removes the required number of parameters from the top of the stack, executes the designated operation, and pushes any resulting values back onto the stack.
During verification, the engine first processes the unlocking script, leaving an intermediate stack populated with signatures, keys, or preimages. The engine then transitions to the locking script, running its operations against that existing stack state. For the input to be considered valid, execution must complete without encountering unassigned opcodes or abort conditions, and the top element remaining on the stack must evaluate to a non-zero truth value.
Common script patterns and verification steps
A widely observed pattern across transaction records is Pay-to-Public-Key-Hash. In this model, the locking script does not contain the recipient's full public key, but rather a double-hashed digest of it. The locking script structure consists of sequential instructions: duplicate the top item, hash the duplicate, verify equality against the designated hash, and finally verify the signature.
To verify this transaction sequence, an analyst or parser follows clear mechanical steps:
- Extract the unlocking script from the spending transaction input. This script pushes an elliptic curve signature followed by a full public key onto the empty stack.
- Extract the locking script from the referenced historical output. This script begins with an opcode that duplicates the public key on the stack.
- Execute the hash instruction, which digests the duplicated key using cryptographic hash functions.
- Push the target public key hash provided by the locking script and execute the equality-verification instruction, which compares the computed hash with the target hash.
- Execute the signature verification instruction. This step extracts the remaining public key and signature from the stack, computes the signature hash of the spending transaction, and checks cryptographic authenticity.
Another standard structure is Pay-to-Script-Hash. Here, funds lock behind the hash of an arbitrary commitment script. The spending input must supply both the input arguments and the full commitment script matching the hash. Once the hash check passes, the interpreter unpacks and executes the commitment script as a secondary phase.
Pitfalls and validation errors in data analysis
Parsing raw transaction inputs and outputs introduces several failure modes for data systems. A frequent mistake is assuming the unlocking script completely contains all authentication data. In transactions that segregate signatures, the unlocking field in the input array may be empty or contain only a reference, while the actual cryptographic proofs are serialized in the transaction witness vector.
Another hazard involves byte-level serialization differences. Data lengths in scripts are preceded by variable-length integer fields or specific push opcodes depending on payload size. Failing to parse these length descriptors correctly shifts the bytecode boundary, causing subsequent opcodes to be misread as raw data, or data bytes to be misread as operational commands.
Finally, analysts must not rely solely on static pattern matching when evaluating transactions. While many transactions follow standardized script templates, arbitrary or non-standard scripts can exist within the consensus rules. Custom scripts must be fully evaluated through a compliant stack interpreter to confirm whether they resolve to true, rather than evaluated through naive regular expressions.
Frequently asked questions
What is the difference between an input script and an output script?
An output script defines the conditions and cryptographic challenges required to spend an allocated value. An input script provides the data arguments, such as signatures and public keys, designed to satisfy those recorded conditions.
How does the execution stack determine whether a spend is valid?
The interpreter runs the unlocking script followed by the locking script, manipulating data elements on a last-in, first-out stack. The spend is considered valid only if the execution finishes without operational errors and leaves a non-zero element on top of the stack.
Where does unlocking data reside in transactions that use segregated witness structures?
In transactions that use segregated witness structures, the unlocking arguments do not reside entirely in the traditional input script field. Instead, they are stored within a separate witness vector included with the transaction data.
bitcoin transaction scripts · scriptPubKey · scriptSig · stack execution model · Pay-to-Public-Key-Hash · Pay-to-Script-Hash · segregated witness
