Bitcoin Script and Taproot

Bitcoin is often described as “not programmable” compared to Ethereum. This is an oversimplification. Bitcoin has a scripting language — Bitcoin Script — that enables surprisingly diverse spending conditions: multisig requiring multiple signers, time-locked funds that cannot be spent until a future block or timestamp, hash-locked contracts enabling payment channels and atomic swaps, and more. The Taproot upgrade (BIP 340-342, activated November 2021) dramatically expanded what’s possible while making complex scripts privacy-preserving: a 100-of-100 multisig looks identical on-chain to a single-key payment. Understanding Bitcoin Script and Taproot is essential for understanding Lightning Network, Discreet Log Contracts (DLCs), and the broader Bitcoin L2 ecosystem.

Bitcoin Script Fundamentals

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:

Amount: The Bitcoin value in satoshis
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:

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

Bitcoin Script Types: Evolution

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:

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

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

Schnorr Signatures

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 Problem MAST Solves

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

CEO + CFO signatures (2 of 2)
Majority board vote (5 of 8 signatures)
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:

The satisfied script (condition used)
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:

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.
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

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

Research

Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. Bitcoin White Paper.

Wuille, P., et al. (2021). Taproot: SegWit Version 1 Spending Rules (BIP-341). Bitcoin Improvement Proposal 341. Bitcoin GitHub Repository.

Wuille, P., et al. (2020). Schnorr Signatures for Secp256k1 (BIP-340). Bitcoin Improvement Proposal 340. Bitcoin GitHub Repository.

Maxwell, G., Poelstra, A., Seurin, Y., & Wuille, P. (2019). Simple Schnorr Multi-Signatures with Applications to Bitcoin. Designs, Codes and Cryptography, 87(9), pp. 2139–2164.

Erhardt, M., & Shikhelman, C. (2021). Taproot Channels Specification (BOLTs PR #835). Lightning Network BOLTs Repository.