Bitcoin Script is the programming language that controls every transaction on the Bitcoin network. It is a simple, stack-based language that defines the exact conditions under which bitcoin can be spent, and every full node on the network runs it every time a transaction is validated. Without it, Bitcoin would be a ledger of numbers with no mechanism to enforce who owns what.
Most users never see the Bitcoin scripting language directly. Their wallets handle it invisibly. But every time you send or receive BTC, two small programs are executing on thousands of computers simultaneously, checking whether the spending conditions have been met. Understanding how that works explains a great deal about why Bitcoin is structured the way it is, and what it can and cannot do compared to platforms like Ethereum.
This article covers how Bitcoin Script works, walks through the main transaction types it enables, explains the Taproot upgrade that modernized the scripting layer in 2021, and covers where the covenant opcode debate stands as of June 2026.
Manage your Bitcoin securely with the self-custody Bitcoin.com Wallet app.
Key Takeaways
- Bitcoin Script is a stack-based programming language built into the Bitcoin protocol that defines the conditions under which any bitcoin output can be spent.
- Every Bitcoin transaction includes two scripts: a locking script (ScriptPubKey) set by the recipient and an unlocking script (ScriptSig) provided by the spender. Both must execute successfully for a transaction to be valid.
- Bitcoin Script is intentionally not Turing complete. It has no loops, no persistent state between executions, and hard limits on script size. This makes every script guaranteed to terminate, which is a security feature, not a limitation.
- The scripting language has evolved through five major formats: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH), and Taproot (P2TR), each expanding what is possible while remaining backward compatible.
- Taproot (November 2021) introduced Schnorr signatures, MAST-based spending paths for privacy, and Tapscript as an updated scripting language with a built-in mechanism for cleaner future upgrades.
- Real-world use cases built on Bitcoin Script include multisignature wallets, time-locked transactions, Hash Time-Locked Contracts (the foundation of Lightning), escrow, and Discreet Log Contracts.
- Unlike Ethereum smart contracts, Bitcoin Script is stateless: each script runs in complete isolation with no knowledge of any other transaction. This is a deliberate architectural choice.
- The most active area of Bitcoin Script development in 2026 is covenant opcodes, particularly OP_CTV (BIP-119) and OP_CAT (BIP-347), which would allow scripts to constrain what a spending transaction must look like. Neither has activated on mainnet yet.
What Is Bitcoin Script?
Bitcoin Script is a stack-based, stateless scripting language built into the Bitcoin protocol. Every transaction output on the Bitcoin network carries a locking script (called the ScriptPubKey) that specifies the conditions for spending the funds. Anyone who wants to spend those funds must provide an unlocking script (called the ScriptSig, or in SegWit and Taproot transactions, the witness data) that satisfies those conditions.
The language takes its structure from Forth, a minimalist stack-based programming language developed in the 1960s. Like Forth, Bitcoin Script reads from left to right, operates on a data structure called a stack, and uses Reverse-Polish Notation (RPN), where operators follow their operands rather than precede them. It executes one instruction at a time, has no loops, and carries no persistent memory between executions.
That last point is the one most people encounter first when learning about Bitcoin Script explained at a protocol level: the language is intentionally not Turing complete. A Turing complete language can perform any computation given enough time and resources. Bitcoin Script cannot, by design, and the reasons for that choice matter a great deal to how the network works.
How Bitcoin Script Works: The Stack Model
To understand how Bitcoin Script works, you need to understand the stack. A stack is a data structure that operates on a Last-In, First-Out (LIFO) basis. Picture a stack of plates: you can only add or remove from the top. In Bitcoin Script, data gets pushed onto the stack and opcodes (operation codes) manipulate whatever is sitting at the top.
When a Bitcoin node validates a transaction, it runs two scripts in sequence:
- The unlocking script (ScriptSig or witness) provided by the person spending the coins. This pushes data onto the stack, typically a digital signature and a public key.
- The locking script (ScriptPubKey) attached to the output being spent. This contains opcodes that operate on the stack data and verify whether the spending conditions are satisfied.
If the script executes without errors and leaves a non-zero value (TRUE) on the stack at the end, the transaction is valid. If it fails or leaves FALSE, the transaction is rejected by the node and never makes it into a block.
This execution is entirely stateless. The script has no knowledge of any previous transaction, no awareness of current balances, and no memory that carries over after the script finishes running. Every script runs from scratch, in isolation, every time.
Step-by-Step: A Standard P2PKH Transaction
Pay-to-Public-Key-Hash (P2PKH) is the original Bitcoin transaction type, in use since 2009. P2PKH addresses begin with "1." Here is what the ScriptPubKey and ScriptSig look like in practice:
Unlocking script (ScriptSig):
<signature> <public key>
Locking script (ScriptPubKey):
OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG
When the node concatenates and executes both together, the stack operations proceed step by step:
- The signature and public key from the ScriptSig are pushed onto the stack
OP_DUPduplicates the public key at the top of the stackOP_HASH160hashes the duplicate (SHA-256 followed by RIPEMD-160), producing a 20-byte hash- The public key hash from the locking script is pushed onto the stack
OP_EQUALVERIFYchecks that the two hashes match. If they do not, execution halts and the transaction fails.OP_CHECKSIGverifies that the signature is valid for the public key
If all steps pass, the stack ends with TRUE and the funds are released. The whole process takes milliseconds and runs identically on every node in the network.
Bitcoin Opcodes Explained
Bitcoin opcodes are the individual commands that make up a script. Each is a single byte, giving 256 possible opcode slots. Of those, roughly 80 are currently active on mainnet. The rest are either reserved, disabled, or assigned to the OP_SUCCESS forward-compatibility mechanism introduced with Tapscript.
Opcodes fall into several categories:
- Data push opcodes push values such as public keys, signatures, and hashes onto the stack
- Arithmetic opcodes perform addition, subtraction, and comparison operations. Notably, multiplication and division are disabled.
- Cryptographic opcodes include OP_SHA256, OP_HASH160, OP_SHA1 for hashing, and OP_CHECKSIG for signature verification
- Flow control opcodes enable conditional logic: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
- Stack manipulation opcodes include OP_DUP (duplicate the top item), OP_DROP (remove the top item), and OP_SWAP (swap the top two items)
Several opcodes were disabled by Satoshi Nakamoto in 2010 after vulnerabilities were discovered in their original implementations. These include OP_CAT (concatenate two stack items), OP_MUL (multiply), and OP_DIV (divide). Their absence has had lasting consequences for what Bitcoin Script can express, and several of the most actively debated Bitcoin upgrade proposals in 2026 involve whether to re-enable some of them.
For the complete opcode reference including hex values and descriptions, the Bitcoin Wiki Script page is the authoritative source.
Why Non-Turing Complete Is a Feature
The standard explanation is that Bitcoin Script has no loops, so scripts are guaranteed to terminate, so the network is protected from infinite execution. That is accurate, but it understates the point.
The deeper argument is about attack surface. A Turing complete language can express arbitrary computation. That expressiveness is also the space where bugs live. Ethereum's Solidity has produced some of the most expensive software vulnerabilities in history. The 2016 DAO hack exploited a reentrancy flaw in a smart contract and caused losses of around $60 million at then-current prices, ultimately leading to a controversial hard fork of the Ethereum network. The broader DeFi ecosystem has seen hundreds of millions of dollars drained through smart contract exploits across multiple years.
Bitcoin Script makes that class of attack structurally impossible. You cannot write a Bitcoin script that calls other scripts, loops until a condition changes, or stores state between transactions. Every script is a bounded, terminating, inspectable program. The maximum script size is 10,000 bytes. The maximum number of non-push opcodes per script is 201. A validator can always calculate the worst-case execution cost before running the script.
For a network holding hundreds of billions of dollars in value, that predictability is worth more than the flexibility you give up. Ethereum solves the unbounded computation problem with gas limits, charging users for each opcode executed and halting scripts that run out of budget. That works, but it introduces its own complexity and failure modes. Bitcoin sidesteps the problem entirely by design.
That said, "not Turing complete" does not mean "not capable of complex logic." Bitcoin Script supports multi-party spending requirements, time-based conditions, hash preimage reveals, and combinations of all of these. The Lightning Network, which routes millions of payments per day, is built entirely on Bitcoin Script primitives.
Script Types: The Evolution From P2PKH to Taproot
Bitcoin's scripting layer has evolved significantly since 2009, with each upgrade introducing a new transaction format while remaining backward compatible with everything that came before.
P2PK (Pay-to-Public-Key, 2009)
The original format, used in the first Bitcoin transactions including Satoshi's payment to Hal Finney in block 170. Funds were locked directly to a full public key rather than its hash. Rarely used in new transactions today because it exposes the public key on-chain before spending, which is considered a weaker security posture than hashing the key first.
P2PKH (Pay-to-Public-Key-Hash, 2009)
The standard format for more than a decade. P2PKH locks funds to a hash of the public key rather than the key itself, keeping the public key private until the moment of spending, producing a shorter 20-byte address, and forming the basis of all addresses beginning with "1." According to on-chain data from Unchained (April 2026), P2PKH addresses currently hold approximately 43% of the mined bitcoin supply.
P2SH (Pay-to-Script-Hash, 2012, BIP 16)
Introduced via soft fork on April 1, 2012, P2SH shifted the burden of complex spending scripts from sender to recipient. Instead of embedding a full locking script in the output, P2SH outputs commit to a 20-byte hash of a "redeem script." The full script is only revealed when the coins are spent. This made multisig practical for ordinary users: a 2-of-3 multisig setup no longer required all three public keys to be visible to the sender at payment time. P2SH addresses start with "3."
For a detailed breakdown of how P2SH validation works at the protocol level, developer.bitcoin.org's transactions guide walks through the redeem script mechanism step by step.
P2WPKH and P2WSH (Native SegWit, 2017, BIP 141)
Segregated Witness, activated in August 2017 at block 481,824, moved signature data outside the main transaction body into a separate witness structure. Witness data receives a 75% weight discount, making SegWit transactions meaningfully cheaper. A standard single-input, two-output P2WPKH transaction weighs approximately 141 virtual bytes, compared to 226 vbytes for the equivalent P2PKH transaction, according to Spark's Bitcoin address types analysis from March 2026. SegWit also fixed transaction malleability, which was a prerequisite for the Lightning Network. Native SegWit addresses start with "bc1q."
P2TR (Pay-to-Taproot, 2021, BIPs 340/341/342)
Taproot activated in November 2021 at block 709,632 and is the most significant upgrade to Bitcoin's scripting layer since SegWit. It introduced Schnorr signatures, a new output type with MAST support, and Tapscript as an updated scripting language. Taproot addresses start with "bc1p."
Taproot and Tapscript: How the Bitcoin Scripting Language Changed in 2021
Taproot is not a single change. It is three Bitcoin Improvement Proposals designed together and activated simultaneously.
BIP 340: Schnorr Signatures
Bitcoin originally used ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi chose it partly because Schnorr signatures were patent-protected at the time. That patent expired in 2008, and Taproot finally brought Schnorr to the protocol.
Schnorr signatures are smaller at 64 bytes versus 71-73 bytes for ECDSA. More importantly, they support key aggregation through a scheme called MuSig2. Key aggregation allows multiple signers to combine their individual keys and signatures into a single aggregate key and signature that is indistinguishable on-chain from an ordinary single-signature payment. A 2-of-3 multisig wallet spending via Taproot's cooperative key path looks identical to a standard payment on the blockchain. That is a real privacy gain for anyone holding bitcoin in a complex custody arrangement.
BIP 341: Pay-to-Taproot and MAST
P2TR introduces a new output type with two spending paths:
- A key path spend using a Schnorr signature, used when all parties agree and want the simplest, cheapest path
- A script path spend using MAST (Merkelized Abstract Syntax Tree, which is the Taproot implementation of the concept)
MAST allows a single output to commit to a tree of multiple spending scripts via a Merkle root. When spending, only the specific condition actually used is revealed on-chain. All other possible spending paths in the tree remain permanently hidden. For a user who has configured a complex spending policy, say "I can spend normally, or two of three trustees can spend after six months, or a recovery key can spend after two years," only the path that is actually executed ever appears on the blockchain.
As of 2024, Taproot's share of Bitcoin transactions had grown to around 42%, largely driven by Ordinals and BRC-20 inscription activity according to Glassnode data cited by Spark in March 2026. That share has fluctuated with market conditions since, but the infrastructure is now standard across major wallets and exchanges. Bitcoin Optech's Taproot topic page tracks ongoing protocol development around Taproot.
BIP 342: Tapscript
Tapscript is the updated scripting language used for script-path spends within Taproot. It shares most opcodes with legacy Bitcoin Script but makes several meaningful changes:
OP_CHECKMULTISIGandOP_CHECKMULTISIGVERIFYare deprecated. The old multisig opcode had a quirk that required pushing a dummy element to the stack as a workaround. Tapscript removes it and replaces it withOP_CHECKSIGADD, which verifies Schnorr signatures one at a time and accumulates a count. Threshold multisig schemes become cleaner and cheaper to execute.- Script size limits per MAST leaf are removed. Individual scripts within a Taproot branch can be arbitrarily large.
- OP_SUCCESS opcodes are the most forward-looking change. In legacy Script, encountering an undefined opcode causes the script to fail. In Tapscript, opcodes in the OP_SUCCESS range cause the script to succeed unconditionally. Future soft forks can assign real behavior to these opcodes by adding constraints on when they succeed, without requiring a new script version or a full re-deployment cycle across the ecosystem. New capabilities can be added to Bitcoin's scripting layer more cleanly than at any previous point in the protocol's history.
Miniscript
Alongside Tapscript, a related project called Miniscript has become increasingly relevant for developers. Miniscript is a structured way of writing a subset of Bitcoin Script that is analyzable, composable, and signable generically. Where raw Script requires manual construction and is difficult to audit, Miniscript scripts can be verified for correctness automatically and combined into larger policies. It does not extend what Script can do but makes what it already does significantly more accessible to developers building wallets and custody tools.
What Bitcoin Script Enables: Real-World Use Cases
The following transaction types are active on Bitcoin mainnet today, all built on Bitcoin Script primitives:
Multisignature (multisig) wallets require M-of-N private keys to authorize a spend. A company treasury might require 3-of-5 approvals for any withdrawal. A married couple might use 2-of-2 for joint savings. With Taproot and Schnorr key aggregation, cooperative multisig spends are now on-chain indistinguishable from standard single-signature transactions.
Time-locked transactions use OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, or CLTV) and OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, or CSV) to prevent funds from being moved before a certain block height or elapsed time. Applications include inheritance planning, employee token vesting schedules, forced savings mechanisms, and penalty transactions used inside Lightning Network channels.
Hash Time-Locked Contracts (HTLCs) combine a hash preimage requirement with a timelock. The spending condition works like this: reveal the preimage of this hash before this block height, or the funds return to the sender. HTLCs are the core primitive of the Lightning Network, enabling trustless payment routing across chains of channels between parties who have no direct relationship.
Escrow arrangements lock funds in a P2SH or Taproot script requiring agreement from multiple parties before release, typically with a third-party arbitrator holding a tiebreaker key.
Discreet Log Contracts (DLCs) use oracle-based Schnorr adaptor signatures to enable financial contracts settled by real-world data such as price feeds or event outcomes, without requiring the oracle to take custody of any funds. DLCs are live on Bitcoin mainnet and are used for Bitcoin-settled options and futures products.
Bitcoin Script vs. Ethereum Smart Contracts
Bitcoin Script and Ethereum's Solidity both define conditions under which funds can move, but they represent fundamentally different architectural choices. The comparison is worth making directly because the differences explain a lot about the tradeoffs each network has accepted.
The fundamental dividing line is statefulness. Ethereum contracts store and modify data that persists across transactions, making lending protocols, decentralized exchanges, on-chain governance, and token standards possible. Bitcoin Script has no equivalent. Each script runs in a vacuum with no knowledge of any other transaction.
This is a deliberate architectural choice, not a gap waiting to be filled. Bitcoin's scripting layer was designed for one specific job: enforcing the conditions for spending bitcoin, predictably and securely, at scale. For that job, statelessness is a strength. The attack surface is smaller, execution is deterministic across millions of independent validators, and there is no category of smart contract exploit at the protocol level because there are no stateful contracts at the protocol level.
Projects that want more programmability on top of Bitcoin build it in layers. The Lightning Network handles payments. DLC protocols handle financial contracts referenced to external data. Layer-2 systems like Ark and the Liquid Network address different scalability profiles. None of this requires modifying the base-layer scripting model.
The Covenant Debate: What Could Change in Bitcoin Script
Bitcoin Script's evolution has always been slow and conservative. The most active development area right now is covenant opcodes, which are proposals that would allow a script to constrain not just who can spend an output, but what the resulting transaction must look like. This is a meaningful expansion of Script's expressive power.
The leading proposals as of June 2026 are:
- OP_CTV (BIP-119, CheckTemplateVerify), authored by Jeremy Rubin, adds a single opcode that commits a UTXO to a specific, predetermined spending template including the transaction's version, locktime, input count, sequences, output count, and outputs. It is non-recursive by design, considered the most conservative major proposal, and primarily targets vaults, congestion control, and certain Lightning improvements. As of April 2026, OP_CTV has concrete deployment parameters on the table specifying a Speedy Trial signaling window, but has not achieved the broad community consensus required for activation, per BlockEden's April 2026 covenant analysis.
- OP_CAT (BIP-347), proposed by Ethan Heilman and Armin Sabouri, would re-enable an opcode that Satoshi disabled in 2010. OP_CAT concatenates two stack items, which is simple in description but broad in implication. When combined with Schnorr signatures, it enables covenant-like transaction introspection. On the Bitcoin signet test network, OP_CAT had generated significantly more developer transactions than either APO or CTV, according to sCrypt's on-chain analysis from late 2024. OP_CAT is already active on the Liquid Network and Fractal Bitcoin with no exploits attributed to it. BIP-347 has an official proposal number and active research behind it, but mainnet activation requires community consensus that does not yet exist.
- LNHANCE bundles OP_CTV with OP_CHECKSIGFROMSTACK (CSFS) and OP_INTERNALKEY, targeting specific improvements to Lightning Network channel construction including non-interactive channel openings and more efficient multi-party channel management.
None of these have activated on Bitcoin mainnet as of June 2026. The technical disagreements between them are largely resolvable. The harder problem is activation mechanics. Bitcoin's soft fork process requires broad consensus, and the covenant debate carries residual tension from previous contentious upgrades. What is clear from the debate is that Bitcoin's scripting layer has meaningful room to grow within its conservative framework. The question being worked through is sequencing and community agreement, not whether the scripting language has a future.
Conclusion
Bitcoin Script is the invisible infrastructure beneath every transaction on the network. Most users never encounter it directly. Wallets construct valid scripts, sign them, and broadcast them without ever exposing the mechanics. But every payment, every Lightning channel, every time-locked plan, every multisig vault runs through the same stack-based Bitcoin scripting language that shipped with the protocol in 2009.
The scripting layer has grown considerably since then, with P2SH making complex spending practical, SegWit cutting fees and enabling Lightning, and Taproot bringing Schnorr signatures, MAST-based privacy, and Tapscript's forward-compatible opcode design. The covenant proposals now in active discussion represent the next potential chapter. Whether any activate, and on what timeline, remains genuinely open as of mid-2026.
Understanding Script does not require being a developer. It does require recognizing that Bitcoin's conservatism, the deliberate limitations, the slow upgrade cadence, the non-Turing completeness, is not a deficiency. The properties that make Bitcoin Script predictable are the same properties that have kept the consensus layer clean for sixteen years.
