Bitcoin Scripts and Smart Contracts: What Works, What Doesn't

Yes, Bitcoin smart contracts exist, they are just rarely called that. Every bitcoin payment is bound to a small program, a script, that defines who may spend it and under which conditions. With it you can build multiple signatures, timelocks, inheritance rules and the payment channels of Lightning. What you can't build: arbitrary programs with loops and their own storage as on Ethereum. That is not an oversight but a choice made for security.

What a smart contract is in the first place

The term comes from computer scientist Nick Szabo, who coined it in the 1990s. He meant contracts whose terms enforce themselves without a court or a bank having to step in. His example was the vending machine: coin in, can out, no trust required.

Today most people think of Ethereum when they hear "smart contract": programs that run on a blockchain, manage their own balances and may be as complex as their authors like. Bitcoin works differently. There is no program "running" anywhere. There are only conditions that are checked once, each time a coin is spent: true or false, spending allowed or not.

For most things that involve money, that goes surprisingly far.

How Bitcoin Script works

How a transaction is made of inputs and outputs is explained in How does a Bitcoin transaction work?. Here only one detail matters: besides the amount, every output contains a locking script. Whoever wants to spend the output later supplies an unlocking script, usually a signature and a public key. Every node puts the two together and runs them. If "true" is left at the end, spending is allowed.

Script is a stack language. Picture a stack of plates: data is put on top, commands take the top plates off, process them and put the result back on top. The commands are called opcodes and start with OP_, for example OP_DUP (duplicate the top value), OP_HASH160 (take a fingerprint), OP_EQUALVERIFY (compare two values, abort if they differ) and OP_CHECKSIG (check a signature).

Satoshi Nakamoto built Script in from the start, in the very first version in 2009. In 2010, after bugs were found, he disabled a number of commands, among them OP_CAT (join two values) and multiplication. Since then Script has grown mainly by carefully giving unused commands a meaning through a soft fork.

An example step by step

The oldest common payment type is called P2PKH, "Pay to Public Key Hash", recognisable by addresses starting with 1. Its locking script says: "Provide a public key whose fingerprint is this one, plus a valid signature for it."

Newer address formats package the script differently; the idea stays. How the formats differ is explained in Bitcoin addresses explained.

Why Script is deliberately not Turing-complete

Script has no loops and no jumps backwards. A script runs once from start to end and is then done. It also has no memory: it only sees the data of the transaction it checks, not the balance of other addresses and not what happened yesterday.

Computer scientists call such a language "not Turing-complete". That sounds like a flaw, but it has three concrete advantages:

• Every script finishes. Nobody can slip in an infinite loop that ties up thousands of nodes.
• The cost is known in advance. How much work checking takes follows from the length of the script. There is no need for a gas system like Ethereum's that prices individual computation steps.
• What a script does can be checked completely. With a few fixed building blocks, a wallet can say for certain under which conditions a coin can be spent. With arbitrary programs that is, in principle, not always possible.

On top come hard limits: a classic script may be at most 10’000 bytes long, contain at most 201 commands, and a single value on the stack may be at most 520 bytes. Tapscript redrew some of these limits in 2021.

The building blocks: signature, hash, time, majority

Almost everything that runs on Bitcoin as a smart contract is made of four conditions.

With OP_IF and OP_ELSE these conditions can be combined into alternatives: "Either A and B sign, or after one year C alone is enough."

Multiple signatures

Multisig is the best-known Bitcoin contract: only someone who supplies m of n signatures may spend. How to protect your savings with it is covered in detail in Multisig wallet: more security through several keys. What is technically interesting here is only that multisig was in the protocol early on and became practical in 2012 with P2SH (BIP 16): since then the sender pays to a short hash, and only the recipient reveals the full script when spending.

Timelocks: bitcoin with an expiry date

Timelocks are the building block that makes Bitcoin contracts really useful. There are two kinds and two places.

Absolute or relative. An absolute timelock says "not before block 1’000’000" or "not before 1 January 2030". A relative one says "not earlier than 144 blocks after this coin arrived", roughly one day later.

In the transaction or in the script. A timelock in the transaction (the nLockTime field, present since 2009) only applies to that one already signed transfer. The sender can spend the coins beforehand with a different transfer. A timelock in the script, by contrast, binds the coin itself: nobody, not even the owner, can touch it before it expires.

HTLC: the contract behind Lightning

Combine a hash puzzle with a timelock and you get a Hash Time-Locked Contract, HTLC for short. In words: "Bob gets the amount if he shows the secret behind this fingerprint. If he doesn't by block X, Alice gets her money back."

That sounds modest, but it solves an old problem: payments across several hops in which nobody has to trust anyone. In the Lightning Network every hop locks its part with the same fingerprint. As soon as the recipient reveals the secret to collect the money, every hop can claim its money backwards along the route. If the recipient never reveals it, all timelocks expire and everyone gets their own back. Either everything goes through or nothing does.

OP_IF
    OP_SHA256 <H> OP_EQUALVERIFY <Bob's key>
OP_ELSE
    <block X> OP_CHECKLOCKTIMEVERIFY OP_DROP <Alice's key>
OP_ENDIF
OP_CHECKSIG

The same pattern allows atomic swaps: two people exchange coins on two different blockchains without an exchange. Both sides lock with the same fingerprint, and whoever uses the secret to collect thereby makes it visible to the other side.

Taproot and Miniscript: contracts nobody sees

Until 2021 every Bitcoin contract had a drawback: when spending, the whole script became public, with every path, including the unused ones. Spending Anna's inheritance plan would have shown the world her brother's emergency path.

Taproot changed that. The conditions sit in a tree, and spending reveals only the branch actually used. If all parties sign together, the spend even looks like an ordinary single signature. Alongside came Tapscript, a revised version of Script with OP_CHECKSIGADD and room for future commands. The details are in Taproot and Schnorr.

The second tool is Miniscript, developed by Pieter Wuille, Andrew Poelstra and Sanket Kanjalkar. It is not a new network rule but a notation for wallets: conditions such as or(pk(Anna), and(pk(Brother), older(52560))) are translated into correct Script automatically, and the wallet can check exactly what the result allows, what it costs and which signatures are missing. Bitcoin Core supports Miniscript in its wallet descriptors. For you this means contracts such as inheritance plans can be built today with ready-made wallets, without writing opcodes by hand.

Bitcoin and Ethereum compared

Ethereum launched on 30 July 2015 with the stated aim of doing what Bitcoin couldn't: arbitrary programs. The two systems differ in almost every basic decision.

Ethereum's gas is the answer to the infinite-loop problem: every computation step costs, and once the gas paid for is used up, the program stops. That works, but it makes the cost of a transaction harder to predict.

What complex contracts can cost

The bigger difference lies in the risk. An Ethereum contract is a program that manages large sums belonging to many people, and every programming error can be attacked in public.

• The DAO, June 2016: An attacker exploited a bug in the contract of an investment fund on Ethereum and drained about 3.6 million ether. The Ethereum community reversed the theft with a hard fork on 20 July 2016. Those who rejected that stayed on the old chain, known since then as Ethereum Classic.
• Parity wallet, November 2017: A user accidentally triggered the self-destruction of a shared code library. More than 500’000 ether in multisig wallets that depended on it have been frozen ever since.

Bitcoin has nothing of this kind in that form: a script locks only one particular coin, not other people's balances, and its few building blocks can be checked completely. Bitcoin's own serious bugs were in the node software, not in user contracts. Why these differences matter to long-term savers is covered in Bitcoin vs altcoins.

What Bitcoin scripts can't do

The limits follow from the same decision that makes Bitcoin safe.

No state. A script can't remember anything. An exchange that computes prices from its reserves, or a loan contract that accrues interest over months, can't be built directly this way.

No outside data. A script knows no prices, no weather, no results. It can only check signatures. Anyone who needs external data has to trust someone who signs it.

No rules on where coins go. This is the most important gap. A script determines who may spend a coin, but not where it may go afterwards. A condition such as "this coin may only go to this vault address, or elsewhere only after 30 days" is not possible today. Such rules are called covenants. Proposals for them, such as CHECKTEMPLATEVERIFY (BIP 119) or reintroducing OP_CAT (BIP 347), are being discussed. As of November 2026 none of them has been agreed; the state of the debate is summarised in Bitcoin soft fork explained.

What this means for you as a bitcoin saver

You don't need to be able to write Script to benefit from it. Three uses are practical today for long-term holders in Germany, Austria and Switzerland:

1. Multisig against the loss or theft of a single key.
2. Timelock wallets as an inheritance or emergency plan that works without third parties and without handing over your seed.
3. Lightning for small, fast payments, secured by HTLCs and timelocks.

For all three: the more paths and conditions, the more you have to back up and document. With a timelock plan that includes not only the keys but the wallet description (the descriptor), without which nobody can find the coins again. A smart contract your heirs don't understand is not a plan.