Bitcoin Script

Coins are not sent to people. They are locked behind a short program, and spending means supplying data that makes the program finish with a true value on top of the stack. The language has no loops and no recursion, and a legacy script stops at 10,000 bytes and 201 operations, so a validator always knows the work will end. That is why bitcoin has never had a runaway contract.

How it works

Bitcoin Script is a stack machine that reads left to right and does nothing else.

Data pushes go onto a stack; operations pop their arguments off it and push results back. There are no variables, no backward jumps, and no way to read anything outside the transaction being validated. A script succeeds when execution completes without error and leaves a true value on top.

Two pieces meet at spending time. The output being spent carries the lock, called the pubkey script. The input spending it carries the proof, called the signature script for older outputs or the witness for segwit ones. They run in sequence with the stack carried between them, never concatenated into a single program, a separation introduced early on once it became clear that a spender who could inject operators into the locking side could rewrite the conditions.

The commonest script in bitcoin's history is worth reading in full. A pay-to-public-key-hash output holds OP_DUP, OP_HASH160, a 20-byte hash, OP_EQUALVERIFY and OP_CHECKSIG. The spender supplies a signature and a public key. Execution pushes both, duplicates the public key, hashes the copy down to 20 bytes, pushes the expected hash, compares the two and aborts if they differ, then checks the signature against a serialisation of the transaction itself. Six steps, and the entire security of a legacy address rests on them.

The limits are deliberate and precise. A legacy or P2SH script may not exceed 10,000 bytes or 201 non-push operations. No single item on the stack may exceed 520 bytes. The stack may not hold more than 1,000 items. One OP_CHECKMULTISIG may not name more than 20 public keys. Every cap exists so the cost of validating a block stays bounded no matter what anybody writes.

The language has grown twice, by giving reserved no-op codes real meaning. BIP65 defined OP_CHECKLOCKTIMEVERIFY in December 2015, letting an output refuse to move before a stated time or height. BIP112 did the same for OP_CHECKSEQUENCEVERIFY, active from block 419,328 in July 2016, adding relative timelocks measured from when the coin was confirmed. Those two opcodes are why Lightning channels, escrow with a deadline, and timelocked inheritance schemes can exist at all.

Why this matters when you buy bitcoin

The address you withdraw to is a script type, and the choice shows up on your next fee.

Spending a legacy pay-to-public-key-hash input costs roughly 148 virtual bytes. Spending a native segwit input costs roughly 68, because the witness discount introduced by BIP141 charges witness data at a quarter rate, and a taproot key-path spend is smaller again. At a 20 sat/vB fee rate that gap is most of the cost of a small withdrawal, repeated every time you move coins. Where an exchange lets you choose the address format you withdraw to, choosing the modern one is a permanent discount.

Script is also what a multisig vault actually is. A 2-of-3 arrangement is a script naming three public keys and demanding two signatures, and whether a given device can display and sign one honestly is a question our hardware wallet reviews take up directly. The same holds for any inheritance plan built on a timelock: the coins are recoverable only if somebody still has the script, which is why output descriptors, the plain-text recipe for rebuilding it, belong in your backup alongside the seed phrase.

One practical warning. When a platform refuses to send to an address you pasted, the cause is almost always that its withdrawal code cannot build that script type, not that your address is wrong. Test any unfamiliar address format with a small amount before moving a balance you care about.

The 184 billion bitcoin bug and the opcodes Satoshi switched off

On August 15, 2010, block 74,638 carried a transaction that created 184,467,440,737.09551616 bitcoin, split into two outputs of roughly 92.2 billion each.

The check that a transaction's outputs did not exceed its inputs used fixed-width signed arithmetic, and outputs large enough to overflow that arithmetic summed to a negative number, so the test passed. A patched client appeared within about five hours, and the honest chain overtook the bad one at height 74,691. Those coins never existed on the chain anyone uses.

That episode, together with a family of related bugs in the string and arithmetic operations, is why fifteen opcodes are permanently disabled: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT and OP_RSHIFT. A transaction whose script merely contains one of them is invalid, executed or not. The disabling was a blunt instrument applied under time pressure, and undoing part of it is live work: BIP347 proposes restoring OP_CAT inside tapscript, where the newer limits make it much harder to abuse.

Bitcoin Script vs tapscript

Tapscript is Bitcoin Script with the rulebook redrawn, and it applies only inside a taproot script-path spend. BIP342 dropped both the 10,000-byte script size cap and the 201-operation cap, disabled OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY, and added OP_CHECKSIGADD in their place so multisignature policies can be batch-verified. Signature checks are metered rather than counted: each input gets a budget of 50 plus the serialised size of its witness, and every executed signature check spends 50 of it. Same stack machine, different accounting.

Bitcoin Script vs a pubkey script

Bitcoin Script is the language; a pubkey script is one program written in it. An output contains a pubkey script, which is the lock. The input that spends it contains a signature script or a witness, which is the key. Both are Bitcoin Script, and calling either one simply "the script" is the commonest source of confusion when reading a raw transaction, because the two halves are evaluated separately and only one of them was committed to when the coins were received.