Crypto Gloss

Bitcoin Script and Taproot

Bitcoin Script is the deliberately limited, stack-based programming language that enables programmable spending conditions on every Bitcoin transaction — from simple single-signature (P2PKH) to complex multisig and time-locked contracts — while Taproot (BIP 340-342, activated November 2021) added Schnorr signatures and MAST (Merkelized Abstract Syntax Trees) to make complex scripts indistinguishable from single-signature transactions on-chain until execution, dramatically improving privacy and efficiency for Lightning channels, multisig wallets, Discreet Log Contracts, and the broader Bitcoin L2 ecosystem.

Bitcoin is often described as “not programmable” compared to Ethereum — this is an oversimplification. Bitcoin Script is intentionally not Turing-complete (no loops, no persistent state), but it enables surprisingly diverse spending conditions. Taproot is the most significant upgrade to Bitcoin’s scripting capabilities since SegWit.

Bitcoin Script Fundamentals

The following sections cover this in detail.

What Is Bitcoin Script?

Bitcoin Script is a stack-based scripting language included in every Bitcoin transaction. Unlike Ethereum’s Turing-complete EVM, Bitcoin Script is intentionally limited — it lacks loops and cannot maintain state across transactions. These limitations are features, not bugs: they prevent computationally expensive scripts that could halt processing and make script execution deterministic and verifiable.

How Script works — the UTXO model:

Every Bitcoin “coin” is technically an Unspent Transaction Output (UTXO) containing:

  1. Amount: The Bitcoin value in satoshis
  2. ScriptPubKey (locking script): The conditions that must be satisfied to spend this UTXO

When spending a UTXO, the transaction must provide a ScriptSig (unlocking script) that, when combined with the ScriptPubKey and executed on a stack machine, returns true.

The stack execution model:

Bitcoin Script uses a last-in-first-out (LIFO) stack:

  • Data is pushed onto the stack
  • OP codes manipulate stack items
  • The final state of the stack determines whether the script succeeds (non-zero item on top = success)

Example (simplified P2PKH):

“`

ScriptSig (unlocking):

ScriptPubKey (locking): OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

“`

Execution:

  1. Push and onto stack
  2. OP_DUP: Duplicate the top item (public_key)
  3. OP_HASH160: Hash the duplicate (produces pubkey_hash)
  4. Push (from the locking script)
  5. OP_EQUALVERIFY: Verify top two items are equal (provided pubkey_hash == expected pubkey_hash)
  6. OP_CHECKSIG: Verify the signature against the public_key and current transaction data
  7. If all verifications pass: success (1 on stack) → UTXO can be spent

Bitcoin Script Types: Evolution

The following sections cover this in detail.

P2PKH (Pay to Public Key Hash) — Original Bitcoin

Standard transaction format since Bitcoin’s launch:

“`

ScriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

“`

How it works:

  • pubkey_hash is RIPEMD160(SHA256(public_key)) — a hash of the public key
  • Spender must provide the actual public key + valid signature
  • The public key is revealed only when spending (before spending, only the hash is known)
  • Bitcoin addresses starting with “1” (e.g., 1BvBMSEYstWetqTFn5Au…)

Privacy implication: Once a P2PKH address is spent, the public key is revealed on blockchain. Reusing addresses means the public key is permanently visible, enabling analysis of spending patterns for that key.

Privacy best practice: Never reuse a P2PKH address after spending from it (BIP-044 hierarchical deterministic wallets derive a new address for every transaction).

P2SH (Pay to Script Hash) — BIP 16 (2012)

Problem solved by P2SH:

Multisig locking scripts (e.g., “require 2 of 3 public keys to sign”) are long. Forcing the sender to include the full script in their transaction was impractical — the script burden was placed on the recipient.

P2SH solution:

  • Recipient provides only the hash of the spending script (the “redeemScript”)
  • The ScriptPubKey locks to the hash: OP_HASH160 OP_EQUAL
  • When spending, the spender provides the actual redeemScript + fulfillment data

Example use case — 2-of-3 multisig:

The redeemScript is: OP_2 OP_3 OP_CHECKMULTISIG

This script requires any 2 of the 3 keys to sign. The P2SH address hash encodes this requirement but doesn’t reveal it until spending.

Bitcoin addresses starting with “3” (e.g., 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy)

Limitation: Still reveals the full script at spend time. For a 10-of-15 multisig, the spending transaction must include all 15 public keys even if only 10 signed, bloating the transaction.

P2WPKH and P2WSH (SegWit) — BIP 141 (2017)

Segregated Witness (SegWit) solved two major Bitcoin problems:

Problem 1: Transaction Malleability

Transaction IDs (txids) were calculated from the entire transaction including the signature data. Signatures could be legitimately modified (same signature, different encoding) changing the txid without invalidating the transaction. This broke Lightning Network preconditions (payment channels need reliable txids for the pre-signed commitment transactions).

SegWit fix: Separate (“segregate”) the signature data (“witness data”) from the transaction data used to calculate the txid. Witness data doesn’t affect the txid, preventing malleability.

Problem 2: Block Size

SegWit introduced a “block weight” concept: witness data counted as 1/4 of the weight of non-witness data, effectively expanding usable block space from ~1MB to ~4MB.

P2WPKH (Pay to Witness Public Key Hash):

  • Native SegWit: OP_0 in ScriptPubKey
  • Spending data provided in the witness field (not traditional ScriptSig)
  • Addresses starting with “bc1q” (bech32 format)

P2WSH (Pay to Witness Script Hash):

  • SegWit equivalent of P2SH: OP_0 in ScriptPubKey
  • The 32-byte hash is SHA256 of the witness script (vs. RIPEMD160(SHA256()) for P2SH)
  • Larger hash = higher collision resistance

P2TR (Pay to Taproot) — BIP 340-342 (2021)

Taproot is Bitcoin’s most significant upgrade since SegWit. It combines:

  1. Schnorr Signatures (BIP 340)
  2. Tapscript (revised scripting for Taproot, BIP 342)
  3. MAST via Taproot construction (BIP 341)

Bitcoin addresses starting with “bc1p” (bech32m format).

Schnorr Signatures

The following sections cover this in detail.

How Schnorr Differs from ECDSA (Bitcoin’s Previous Signature Scheme)

ECDSA (Elliptic Curve Digital Signature Algorithm): Bitcoin’s original signature scheme. Works, but has a practical limitation: multiple signatures do not compose linearly. Verifying a 2-of-2 multisig requires verifying each signature independently.

Schnorr signatures: A mathematically different signature scheme over the same elliptic curve (secp256k1) with a key property: linearity.

Key advantage — Key aggregation (MuSig2):

With Schnorr, multiple signers can aggregate their public keys into a single combined key: P_combined = P1 + P2 + P3 (roughly — the actual MuSig2 protocol has additional nonce randomization to prevent rogue key attacks).

A 2-of-2 Schnorr multisig looks identical to a single-key signature on the blockchain. There is no way for blockchain observers to distinguish “Alice and Bob jointly signed” from “Carol signed alone.”

Implications:

  • Lightning Network channels: Schnorr makes channel funding transactions indistinguishable from single transactions on the blockchain, improving privacy
  • Multisig wallets: Corporate multisig (board approval required) now has same on-chain footprint as individual wallet
  • CoinJoin: Collaborative transaction mixing becomes more efficient and private

Batch verification: Schnorr enables batch verification of multiple signatures simultaneously (mathematically cheaper than verifying N signatures one by one). For Bitcoin full nodes, this reduces signature validation cost — important for blockchain synchronization.

MAST (Merkelized Abstract Syntax Trees)

The following sections cover this in detail.

The Problem MAST Solves

Complex Bitcoin scripts often have multiple possible spending conditions — for example, a corporate vault might allow:

  1. CEO + CFO signatures (2 of 2)
  2. Majority board vote (5 of 8 signatures)
  3. Time-locked recovery path (after 1 year, any single trustee)

With pre-Taproot scripts: All three conditions must be included in the spending transaction even if only one is used. A 5-of-8 multisig board vote reveals all 8 public keys even though only 5 signed, bloating the transaction and revealing unused conditions.

MAST Solution

MAST organizes script alternatives into a Merkle tree:

  • Each leaf of the tree is a separate spending script
  • The root of the Merkle tree is a cryptographic commitment to all scripts

Spending: The spender provides only:

  1. The satisfied script (condition used)
  2. A Merkle proof (path from the leaf to the root)

Unexecuted branches remain hidden.

For the corporate vault example:

  • If CEO + CFO sign, only the 2-of-2 script is revealed — the board vote and recovery path are invisible
  • If the board votes, only the 5-of-8 script is revealed — and only the 5 signing keys, not all 8
  • The unused recovery path is never revealed

Privacy improvement: Blockchain analysis cannot determine which spending pathways exist for an unspent output — only which one was used when spent.

Taproot: The Full Picture

Taproot combines Schnorr key aggregation with MAST via a clever construction:

A Taproot output contains a single tweaked public key: Q = P + hash(P, script_root) * G

Where:

  • P is the “internal key” (can be a Schnorr-aggregated key)
  • script_root is the root of the MAST Merkle tree of alternative scripts

Spending options:

  1. Key path: If all conditions can be represented as Schnorr key aggregation (e.g., all parties agree), the spender provides a single signature against Q. This looks exactly like a single-key P2WPKH transaction — no script visible.
  2. Script path: If key path isn’t used, spender reveals the internal key P, the Merkle proof, and satisfies the specific script.

The privacy win: In the “cooperative” case (all parties agree), every Taproot spend looks identical regardless of whether it’s a single signer, a Lightning channel close, a 100-party multisig, or a complex DLC contract. Blockchain observers cannot distinguish these cases unless the script path is used.

Practical Applications of Taproot

The following sections cover this in detail.

Lightning Network

Pre-Taproot Lightning channels used 2-of-2 P2WSH multisig — identifiable as Lightning channels on-chain. Post-Taproot Lightning (Taproot channels / Simple Taproot Channels): Channel opening and cooperative closing use key path spending, indistinguishable from regular single-sig transactions.

Discreet Log Contracts (DLCs)

DLCs enable trustless outcome-contingent contracts on Bitcoin using oracle attestations. For example: a BTC/USD settlement contract resolved by a price oracle signing the final price. DLCs use Taproot to:

  • Pre-sign every possible outcome’s adaptor signature
  • The winning outcome can be settled without revealing other possible outcomes
  • Counterparty privacy: the DLC contract looks like a normal transaction

FROST and Threshold Signatures

FROST (Flexible Round-Optimized Schnorr Threshold signatures) enables t-of-n threshold signatures where any t participants can sign without revealing the full key set. Used by:

  • Bitcoin custodians (t-of-n key sharding)
  • Distributed validator technology for staking
  • Bitcoin L2 bridges using threshold multisig

Taproot Adoption

As of 2024:

  • Taproot output creation: Growing but not yet dominant (~55–60% of daily transactions include at least one Taproot output)
  • Wallet support: Bitcoin Core, Sparrow, Coldcard, Ledger, Trezor all support P2TR
  • Exchange support: Major exchanges increasingly generate Taproot withdrawal addresses
  • Lightning: Simple Taproot Channels in active development/deployment

History

  • 2009 — Bitcoin launches with Bitcoin Script; P2PKH (Pay to Public Key Hash) is the standard transaction format from genesis
  • 2012 — P2SH (BIP 16) activates; enables multisig with compact “3…” Bitcoin addresses
  • August 2017 — SegWit (BIP 141) activates; fixes transaction malleability (enabling Lightning); introduces P2WPKH and P2WSH; “bc1q…” addresses
  • November 2021 — Taproot (BIP 340, 341, 342) activates at block 709,632; Schnorr signatures, MAST, and Tapscript go live; “bc1p…” addresses
  • 2023–2024 — Simple Taproot Channels deployed on Lightning; Taproot output creation grows to ~55-60% of daily transactions; FROST threshold signature schemes mature

Common Misconceptions

  • “Bitcoin is not programmable.” — Bitcoin has a scripting language capable of multisig, time locks, hash locks, and (via Taproot) MAST-based complex conditions. The accurate statement is that Bitcoin Script is intentionally not Turing-complete — it lacks loops and cross-transaction state. This is a deliberate security design, not a limitation.
  • “Taproot makes all Bitcoin transactions more private.” — Taproot dramatically improves privacy for the “key path” spend (cooperative case, where all parties agree), making complex scripts look like single-key transactions. If the “script path” is used (a dispute or non-cooperative close), the executed script is revealed. Privacy improvement applies to cooperative transactions.

Social Media Sentiment

  • r/Bitcoin / r/bitcoindev: Taproot adoption progress, opcode proposals (OP_CAT, OP_CTV), and Lightning channel upgrades are closely tracked; anniversary posts appear on Taproot activation date.
  • X/Twitter: Bitcoin Core developers and Lightning developers are active; Taproot and Schnorr signature improvements are frequently discussed alongside Bitcoin L2 implications.
  • Discord (Bitcoin developers): Script development, DLC implementations, FROST threshold signatures, and Lightning channel upgrades are active technical topics.

Last updated: 2026-04

Related Terms

See Also

Sources