Bitcoin Script

Bitcoin Script is the small, stack-based programming language Bitcoin uses to express the conditions for spending coins. Every coin on the network is not "in an account" but locked behind a tiny program; spending it means supplying data that makes the program evaluate to true. Script resembles Forth: instructions push data onto a stack and operate on what is there, executing strictly in sequence. Crucially, it is intentionally not Turing-complete — no loops, no arbitrary jumps. Every script's execution cost is bounded and predictable, which means a node can validate any transaction in known time and a malicious script can never run forever. Where other systems chased expressive smart contracts, Bitcoin chose verifiability: less power, more certainty.

Locking and unlocking

Every spendable output carries a locking script (historically the scriptPubKey) that states its spending conditions. A transaction that wants those coins supplies an unlocking script (the scriptSig, or a witness in modern transactions) that satisfies them. At validation, the node runs the combination; the spend succeeds only if execution completes without error and leaves a true value on top of the stack. The workhorse pattern is pay-to-public-key-hash: the lock says "present a public key hashing to this value, plus a valid signature," and the unlock provides both, with OP_CHECKSIG verifying the signature over the transaction. Other everyday patterns include multisig (m-of-n keys must sign), hash locks (reveal a secret preimage — the atom inside Lightning's payment routing), and timelocks that make coins unspendable until a height or date, the primitive behind every escrow and channel-refund path.

Evolution of the language

Script's history is one of careful pruning and extension. Early on, Satoshi disabled a set of opcodes after vulnerabilities surfaced — a scar that still shapes upgrade caution today. Pay-to-script-hash (2012) let complex scripts hide behind a short hash, paid for by the spender rather than the sender. SegWit (2017) moved unlocking data into a separate witness, fixing transaction malleability and clearing the path for Lightning. Taproot (2021) introduced Tapscript and Schnorr signatures, letting elaborate spending conditions hide inside what looks like a single-key payment — cheaper, and more private, since unused conditions are never revealed. Proposed additions such as the covenant opcode CTV would extend what Script can express, always through backward-compatible soft forks and years of adversarial review.

Why the restraint matters

Equally defining is what Script deliberately cannot do. A script sees only the transaction spending it — not the chain's state, not account balances, not other contracts — so coins cannot carry open-ended rules about their own descendants. That boundary is exactly where the covenant debate lives: proposals to let outputs constrain their spending transactions extend Script's reach one carefully bounded step without granting general programmability. The pattern repeats throughout Bitcoin's history — expressiveness is added grudgingly, in the smallest increment that solves a real problem, because every added power is a permanent addition to the attack surface of everyone's money.

Script's austerity is a decentralization decision. Because every program is cheap to verify, a full node validating every spending condition in the chain runs comfortably on a Raspberry Pi — no datacenter required to check the rules yourself. Bounded execution also shrinks the attack surface: there is no gas metering to game and no halting problem to exploit. Writing raw Script correctly is still expert work, which is why Miniscript exists — a structured layer that composes into provably analyzable Script, so wallets can reason about what a script actually guarantees. For the individual opcodes that make up the language, see opcode; for where the language's guarantees ultimately bind, remember that every locking script is just a condition the whole network agrees to enforce on your behalf.