Bitcoin Scripting in 2026: How Taproot Rewrote the Rules

Bitcoin has a native programming language almost no one talks about, and since Taproot activated in November 2021, that language became dramatically more capable. Understanding Bitcoin scripting is the difference between treating Bitcoin as a simple ledger and seeing it for what it actually is: a programmable settlement layer with surprisingly sophisticated spending conditions.

This guide covers the full arc from the original script types through to Tapscript and Pay-to-Taproot, with practical examples designed for developers and technically curious readers who want to understand how Bitcoin actually enforces ownership in 2026.

What Bitcoin Script Is (and What It Is Not)

Bitcoin Script is a stack-based, intentionally limited programming language embedded in every Bitcoin transaction. Every time a transaction output is spent, the network evaluates two pieces of script: the locking script (called scriptPubKey), which sets the conditions for spending, and the unlocking script (called scriptSig or, in modern transactions, the witness), which provides the data that satisfies those conditions.

Script is not Turing-complete. It has no loops, no recursion, and no persistent state. This is not an accident or a limitation of early design thinking. It is a deliberate security property. A language that terminates predictably in bounded time cannot be exploited for denial-of-service attacks through infinite loops, and it cannot accumulate side-effects that complicate validation across nodes. Every node on the network re-evaluates these scripts independently, so predictability and determinism are not optional properties.

What Script can do, even within those limits, is more than most people assume. It can enforce multi-party authorization, time locks, hash preimage reveals, and with Taproot, it can do all of these things simultaneously in a Merkle tree structure that only reveals the branch actually used for spending.

How Bitcoin Script Executes: The Stack Model

Script execution uses a last-in, first-out stack. Instructions, called opcodes, either push data onto the stack or perform operations on the items already there. When the script finishes executing, a single non-zero value remaining at the top of the stack means the spending conditions were met. An empty stack or a top value of zero means the transaction is invalid.

A simplified example: an opcode like OP_ADD pops the top two stack items, adds them, and pushes the result. OP_EQUAL pops two items and pushes 1 if they match or 0 if they do not. OP_VERIFY pops the top item and fails the script immediately if it is zero.

Cryptographic opcodes work the same way but operate on public keys and signatures. OP_CHECKSIG pops a public key and a signature, verifies that the signature matches the transaction hash under that public key, and pushes 1 on success or 0 on failure. This single opcode is the mechanism behind the most common form of Bitcoin ownership.

The stack model makes it straightforward to reason about what a script is doing. You read it sequentially, maintain a mental image of the stack state, and the final state tells you whether the spend is valid. That traceability is part of why Bitcoin Script has aged well even as the transaction formats around it evolved considerably.

The Major Script Types: From P2PKH to P2TR

Bitcoin has gone through several address and script format generations since 2009. Each one addressed limitations in the previous format without breaking backward compatibility. In 2026, all four generations remain spendable on the network, though new outputs are almost exclusively created using SegWit or Taproot formats.

P2PKH: The Original Pay-to-Public-Key-Hash

P2PKH (Pay-to-Public-Key-Hash) is the format Satoshi used in the earliest Bitcoin transactions. Addresses starting with 1 use this format. The locking script looks like this:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

To spend it, the user provides a public key and a signature. The script duplicates the public key, hashes it, checks it against the embedded hash, and then verifies the signature. Every step is visible on-chain. The full public key is revealed at spend time, which is a privacy consideration compared to modern formats.

P2PKH inputs are relatively large (around 148 bytes) because they must carry the full signature and public key in the transaction body. In a fee-per-vbyte environment, that size has a direct cost, which is one reason legacy addresses have declined in use.

P2SH: Enabling Multisig and More Complex Conditions

P2SH (Pay-to-Script-Hash), introduced through BIP 16 in 2012, addressed a fundamental UX and size problem. Instead of putting the full spending conditions in the locking script, P2SH lets the sender lock funds to the hash of a script. The receiver, at spend time, reveals the full script (called the redeemScript) and provides the data to satisfy it.

Addresses starting with 3 use P2SH. The locking script is compact:

OP_HASH160 <scriptHash> OP_EQUAL

The complexity of the actual spending conditions is shifted to the spender, not the sender. This made multisig practical for the first time: a business could give customers a 2-of-3 multisig address without the customer needing to understand or construct the full multisig script themselves.

P2SH is still widely used in 2026 for compatibility reasons, but it has known limitations. The redeemScript is revealed on-chain when spent, so complex scripts with many branches expose all branches even when only one was used.

P2WPKH and P2WSH: SegWit Script Types

The SegWit upgrade (BIP 141, activated August 2017) introduced a structural change to how witness data is handled. Signatures and public keys moved into a separate witness field, outside the transaction body. This reduced the effective byte weight of signature data and fixed transaction malleability.

P2WPKH (native SegWit, addresses starting with bc1q) is the SegWit equivalent of P2PKH. P2WSH is the SegWit equivalent of P2SH. Both formats are smaller on-chain than their legacy counterparts and carry lower fees as a result. P2WPKH became the recommended default for most wallets through roughly 2021 to 2023, and remains widely supported across all active exchanges and wallets in 2026.

The scriptPubKey for P2WPKH is just:

OP_0 <20-byte pubKeyHash>

Validation logic moved partially into a new script evaluation path called the witness program, but the conceptual model remains the same: hash a key, check a signature.

P2TR: Taproot and the New Standard

P2TR (Pay-to-Taproot) is the address format activated with Taproot in November 2021 via BIP 341. Addresses begin with bc1p. It is the current recommended standard for new outputs in 2026.

P2TR is structurally different from all prior formats in several important ways. The locking script encodes an x-only public key that is itself a commitment to both a key-path spend and an optional script tree:

OP_1 <32-byte x-only tweaked pubkey>

The simplest case, called the key-path spend, lets the holder sign with a Schnorr signature under the tweaked key. On-chain, a key-path P2TR spend looks identical to a simple single-signature transaction, even if the underlying key was constructed from a multi-party Schnorr key aggregation. This is a significant privacy improvement: a complex 2-of-3 multisig setup can spend in a way that is indistinguishable from a single-signature spend.

When more complex conditions are needed, the script-path spend reveals a single branch from the Merkle tree committed in the tweaked key. The other branches remain hidden. This is the MAST mechanism described in the next section.

A single P2TR input spending via key-path costs approximately 57.5 vbytes, compared to about 68 vbytes for P2WPKH, making it roughly 15 percent more efficient in fee terms for single-sig use cases.

Tapscript and MAST: What Changed with Taproot

Tapscript is the updated scripting language that executes in the script-path of Taproot transactions, defined in BIP 342. It shares most opcodes with legacy Script but introduces meaningful differences.

The most significant change is the replacement of OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY with OP_CHECKSIGADD. The old multisig opcode had an off-by-one quirk that required pushing a dummy element to the stack, a workaround that every multisig script in Bitcoin history has carried. Tapscript removes it. The new model lets scripts verify Schnorr signatures one at a time and accumulate a count, making threshold schemes more composable and cheaper.

Tapscript also introduces OP_SUCCESS opcodes. Numerous previously disabled opcodes are redefined so that if encountered, they unconditionally make the script succeed. This is a forward-compatibility mechanism: future soft forks can assign real behavior to these opcodes by constraining when they succeed, without needing to carve out entirely new script evaluation paths.

MAST (Merkelized Abstract Syntax Tree) is the structural innovation that Taproot brings to script trees. The idea is that a single P2TR output can commit to a tree of spending conditions, where each leaf is a distinct script. When spending, the user reveals only the leaf they are using, plus the Merkle proof that it is part of the committed tree, without revealing any other leaves.

The privacy and efficiency implications are substantial. A contract with five possible resolution paths, say a simple payment, a timeout refund, a dispute arbitration branch, a hash preimage path, and an emergency recovery condition, commits to all five in a single 32-byte key tweak. On-chain, only the path taken is ever revealed. The other four conditions, including their very existence, remain completely private. For use cases like payment channels and time-locked vaults, this means the happy path looks like a simple key-path spend, and the fallback script paths are only exposed if the happy path fails.

As of mid-2026, Taproot output creation has grown steadily. Most hardware wallets and major software wallets now generate P2TR addresses by default, and exchange support for P2TR withdrawals has expanded significantly, though a handful of older platforms still route to P2WPKH for compatibility reasons.

Practical Bitcoin Script Examples (Reading Real Scripts)

Understanding what a script does requires being able to read it. Here are three real script patterns with step-by-step explanations.

Standard P2PKH locking script:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

With unlocking data <sig> <pubKey>, execution goes: push sig, push pubKey, OP_DUP duplicates pubKey, OP_HASH160 hashes it to 20 bytes, the embedded hash is pushed, OP_EQUALVERIFY checks they match (fails if not), OP_CHECKSIG verifies the signature against the original pubKey. Success leaves 1 on the stack.

2-of-3 multisig P2SH redeemScript:

OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG

The numbers push threshold and total count. OP_CHECKMULTISIG checks that at least 2 of the 3 provided signatures are valid against the provided public keys. The dummy element requirement (push OP_0 before the signatures) is a quirk fixed by Tapscript's OP_CHECKSIGADD.

Tapscript time-locked recovery leaf:

<locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubKey> OP_CHECKSIG

This script can only be satisfied after a specific block height or timestamp, and only by the holder of the corresponding private key. Used as one leaf in a MAST tree, it represents a recovery path that is invisible unless the primary key-path spend fails and this branch is needed.

These three examples span roughly a decade of scripting practice, from basic ownership verification to conditional time-locked recovery in a privacy-preserving Merkle structure.

Limitations of Bitcoin Script and Why They Are Intentional

The constraints of Bitcoin Script come up in any comparison with Ethereum's Solidity or other smart contract platforms, and they are worth addressing directly.

Script has no loops. It cannot iterate over a dataset of unknown size, call external contracts, or read state from anywhere other than the spending transaction itself. It does not maintain persistent variables. Every execution is stateless and self-contained.

These properties mean Script cannot do many things developers expect from a general-purpose language. It cannot implement a decentralized exchange with an order book, maintain a token registry, or execute arbitrary computation on-chain.

What it can do is enforce ownership conditions on individual UTXOs with cryptographic precision and in a way that every node can verify in microseconds with no risk of infinite loops or state explosion. The security model is different: rather than a global programmable state machine, Bitcoin Script defines per-coin spending rules that compose through transaction structure rather than through shared state.

Covenant proposals in 2026, including discussions around OP_CAT re-enablement through BIP 347 and OP_CTV, aim to extend Script's expressiveness modestly while preserving these core safety properties. The community debate around these proposals reflects the genuine tradeoffs involved: each additional capability creates new attack surface or complexity that must be understood and validated across the entire network.

The intentional simplicity of Script is not a bug. It is a design choice that prioritizes security and verifiability over expressiveness, and Tapscript refines that choice rather than abandoning it.

Frequently Asked Questions

What is Bitcoin Script used for?

Bitcoin Script is the language that defines the spending conditions on every Bitcoin output. It determines who can spend a coin and under what conditions, ranging from a simple signature check to time locks, multisig thresholds, and Taproot script trees.

Is Bitcoin Script Turing-complete?

No. Bitcoin Script deliberately lacks loops and persistent state, which makes it impossible to write programs that run indefinitely. This is a security feature: every script terminates in predictable time, preventing denial-of-service attacks through computation.

What is the difference between P2PKH and P2TR?

P2PKH is the original Bitcoin address format from 2009, requiring the spender to reveal a public key and signature on-chain. P2TR is the Taproot format activated in 2021, which supports both simple key-path spends using Schnorr signatures and complex MAST script trees, with greater privacy and lower fees.

What did Taproot change about Bitcoin scripting?

Taproot introduced Tapscript as the new execution environment for script-path spends, added MAST support so only the used spending condition is revealed, replaced the old multisig opcode with OP_CHECKSIGADD, and enabled Schnorr signatures that allow key aggregation. Together these changes made complex spending conditions cheaper, more private, and more composable.

What is MAST in Bitcoin?

MAST stands for Merkelized Abstract Syntax Tree. In Taproot, it allows a single output to commit to a tree of multiple spending scripts via a Merkle root. When spending, only the used branch and its Merkle proof are revealed on-chain, keeping all other possible spending conditions private.

What are Tapscript OP_SUCCESS opcodes?

OP_SUCCESS opcodes are previously-disabled opcode slots in Tapscript that unconditionally validate any script containing them. They serve as reserved upgrade space: future soft forks can assign real behavior to these slots by narrowing the conditions under which they succeed, without requiring a new script version.

Can Bitcoin Script be used for smart contracts?

Bitcoin Script supports a constrained form of programmable spending conditions often described as smart contracts, including multisig, time locks, hash locks, and Taproot script trees. It is less expressive than Ethereum's Solidity by design, but current covenant proposals aim to extend its capabilities while preserving the security properties that make Bitcoin Script predictable and safe.

Conclusion

Bitcoin scripting has traveled a long way from the original P2PKH pattern that secured the first coins in 2009. The addition of P2SH unlocked practical multisig. SegWit cleaned up transaction structure and reduced fees. Taproot and Tapscript, now the active standard in 2026, introduced MAST, Schnorr signatures, and a forward-compatible opcode model that positions Bitcoin's scripting layer for continued evolution without sacrificing the safety properties that make it trustworthy. For developers building on Bitcoin or anyone trying to understand what the network actually does under the hood, learning Script is not optional background knowledge. It is the foundation on which every transaction is built. To understand how Bitcoin reaches consensus on the validity of those transactions, see the Bitcoin proof of work explained guide on CoinTalk. For a look at how newer Bitcoin protocols are extending the ecosystem at the application layer, the Bitcoin Runes protocol coverage is a useful next read.