Protocol & Mining
Bitcoin Script, and what its limits buy
Protocol referenceSource: Bitcoin Developer Guide, Transactions and ScriptsOpcode behaviour and standard script types follow the protocol documentation.
A stack, and a list of operations
Script is evaluated as a stack machine. The script is a sequence of operations, and each one either pushes a value onto the stack or consumes values from it and pushes a result. A spending condition is satisfied when the script runs to completion and leaves a true value on the stack. There are no variables in the usual sense, no named storage, and no control flow beyond a conditional branch. The whole language is a few hundred operations, most of which are arithmetic, comparison, or cryptographic checks.
The two halves of a spend are evaluated together. The output being spent carries a script, called the scriptPubKey, which states the condition. The spender supplies a script, called the scriptSig, and the data it carries. The two are concatenated and run as one program, with the spender's data placed on the stack first. A signature check is therefore not a special case in the language; it is an operation that consumes a signature and a public key and pushes true or false, exactly as an addition consumes two numbers.
This uniformity is what makes the language extensible without being complex. A new spending condition is a new arrangement of existing operations, not a new kind of transaction. The address types page describes the standard arrangements a payer is likely to meet, and the Taproot page describes how a condition can be hidden inside a tree of scripts.
Why it is not Turing-complete
Script has no loops and no recursion. A program written in it cannot run for an unbounded number of steps, because the number of operations it can execute is fixed by its own length. This is the property that makes validation tractable. Every node must evaluate every spending condition in every block, and it must be able to decide how long that will take before it starts. A language that permitted unbounded computation would allow a spender to construct a condition that takes an arbitrary amount of work to check, which would be a denial-of-service vector against the entire network.
The alternative to forbidding loops is to charge for execution, as general-purpose smart-contract platforms do with a metered gas budget. That approach works, and it introduces a pricing mechanism into the act of validation: a node must track consumption, and a transaction must carry a limit and a price. Bitcoin's designers chose the simpler route. By making the language incapable of unbounded execution, they removed the need to meter it at all. The cost is expressiveness, and the benefit is that validation is a fixed, predictable amount of work.
The limits are not only about loops. Script also restricts which operations are permitted in which context, and the reference implementation applies additional standardness rules about which scripts it will relay. A script that is valid under the consensus rules may still be non-standard and refused by most nodes. The distinction is the same one drawn on the node verification page: consensus decides validity, policy decides welcome.
The standard types
In practice almost every output on the chain uses one of a small number of standard forms. Pay to public key hash requires a public key that hashes to a recorded value and a signature that verifies against it. Pay to script hash records the hash of a script and requires the spender to supply the script and satisfy it. Pay to witness public key hash and pay to witness script hash are the SegWit equivalents, with the condition expressed as a witness program rather than as a script. Taproot outputs commit to a single key and optionally to a script tree.
Each of these is a specific arrangement of the same underlying operations, and each exists because it solves a problem the previous one did not. P2SH moved complexity out of the address so a payer did not need to understand the condition. The witness forms moved signature data into a discounted part of the block so the same payment cost less. Taproot made a cooperative spend indistinguishable from a simple one. The progression is a sequence of refinements to the same idea rather than a series of replacements.
What the standard types share is that they are all verifiable in bounded time and all expressible in a language without loops. That is the constraint that shaped them, and it is why the language's limits are better understood as the reason the system works than as a shortcoming to be worked around. The SegWit page covers the change that introduced the witness forms, and the UTXO model page explains what an output is before a condition is attached to it.
Sources
- Bitcoin Developer Guide, Transactions — scriptPubKey, scriptSig and the standard output types.
- Bitcoin Developer Guide, Transaction reference — the opcode set and the script evaluation rules.
- Bitcoin Core, policy documentation — the standardness rules that decide which scripts are relayed.
Related reading
- Protocol, Transactions & MiningThe supply schedule, transaction mechanics and mining economics behind the price.
- Proof of WorkThe hash puzzle, the target and nonce, and why accumulated work secures the chain.
- Difficulty AdjustmentThe 2,016-block retarget, its caps, and the ten-minute target it defends.
- HashrateWhat hashrate measures, why it is estimated, and how it differs from difficulty.
- Mining PoolsPooled hash rate, share accounting, payout schemes and centralisation.
- Miner RevenueThe block subsidy plus fees, and how the mix changes across subsidy epochs.