Script Path Spend

What Is a Script Path Spend?

A script path spend is one of two ways to spend a Pay-to-Taproot (P2TR) output, as defined in BIP 341. Every P2TR output commits to a tweaked public key that encodes both an internal key (used for the simpler key path) and the Merkle root of a tree of scripts. When the key path is not viable (for example, because multiple independent parties need to enforce specific conditions), a spender can fall back to the script path: revealing a single script leaf from that tree, proving its inclusion via a Merkle proof, and providing witness data that satisfies the script.

The script path exists so that complex spending policies (timelocked recovery, hash lock conditions, threshold multisig fallbacks) can be embedded in any Taproot output without affecting the common case. If all parties cooperate, they use the key path and the scripts are never revealed. If cooperation breaks down, the script path guarantees that pre-agreed conditions can still be enforced on-chain, trustlessly.

How It Works

A Taproot output locks funds to a tweaked public key Q. This key is computed by taking an internal public key P and tweaking it with the Merkle root of a script tree:

t = tagged_hash("TapTweak", P || merkle_root)
Q = P + t * G

The tagged_hash function (defined in BIP 341) domain-separates hashes by prepending a tag-specific prefix. This ensures that hashes used for tweaking cannot collide with hashes used for leaf computation or branching.

To spend via the script path, the spender constructs a witness with three categories of data:

1. The data that satisfies the script (signatures, preimages, or other values the script expects on the stack)
2. The script itself (the exact bytes of the executed leaf)
3. A control block containing the internal key, the leaf version, and the Merkle path connecting the leaf to the tree root

Witness Structure

The witness stack for a script path spend is ordered as follows:

[script_input_1, script_input_2, ..., script, control_block]

The control block is always the last element, and the script is the second-to-last. Everything before the script becomes the initial stack for script execution under Tapscript (BIP 342) rules.

Control Block Structure

The control block is 33 + 32m bytes, where m is the number of Merkle path nodes (0 to 128):

The current Tapscript leaf version is 0xc0. The control byte is either 0xc0 (even y-parity) or 0xc1 (odd y-parity). The maximum tree depth of 128 levels means a single Taproot output can theoretically commit to 2¹²⁸ script leaves.

Validation Steps

When a node validates a script path spend, it performs these steps:

1. Extract the leaf version from the control byte: v = c[0] & 0xfe
2. Extract the internal key P from bytes 1 through 32
3. Compute the tapleaf hash: tagged_hash("TapLeaf", v || script_length || script)
4. Walk the Merkle path: for each sibling hash, compute the branch hash by sorting the two children lexicographically and hashing them with tagged_hash("TapBranch", ...)
5. Compute the tweak from the internal key and the reconstructed Merkle root
6. Verify the resulting tweaked key matches the output key Q (including y-parity)
7. Execute the script against the remaining witness stack under Tapscript rules

Script Path vs Key Path: Cost Comparison

The witness discount introduced by SegWit means witness data costs 1 weight unit per byte, while non-witness data costs 4. This makes script path spends cheaper than they would be under legacy accounting, but they still carry more witness data than key path spends.

Key path spends are always the cheapest option. Script path spends add overhead from the control block (minimum 33 bytes, plus 32 bytes per Merkle tree level) and the revealed script. However, even script path spends are significantly cheaper than legacy P2WSH multisig because only the executed branch is revealed rather than every public key and the entire redeem script.

Privacy Benefits

Script path spending provides strong privacy through selective disclosure, a direct consequence of the MAST structure:

• Only the executed script leaf appears on-chain. If a script tree has ten possible spending conditions, the nine unused branches remain completely hidden.
• Observers cannot determine how many alternative scripts existed. The Merkle path reveals the tree depth at the executed leaf but not the total number of leaves or the shape of the tree.
• Unspent outputs are indistinguishable. A P2TR output with a complex 20-leaf script tree looks identical on-chain to one with no scripts at all: both are a single 32-byte x-only public key.
• Unused branches cost zero fees. Complex contracts can embed many spending paths (timelocks, hash locks, dispute resolution, recovery) without any on-chain footprint until one is actually used.

This is a major improvement over P2SH and P2WSH, where spending reveals the entire redeem script including all branches, public keys, and conditions.

Use Cases

Multisig with Timelocked Recovery

A common pattern places the cooperative case (all signers agreeing via MuSig2 or FROST) in the key path and fallback conditions in script leaves. For example, a 2-of-3 corporate treasury might structure its Taproot output as:

• Key path: all three signers cooperate via key aggregation (cheapest, most private)
• Script leaf 1: any two of three using Tapscript's OP_CHECKSIGADD (fallback if one signer is unavailable)
• Script leaf 2: a single recovery key plus a 6-month timelock via OP_CHECKLOCKTIMEVERIFY (inheritance or emergency recovery)

Lightning Network Channels

Simple Taproot Channels use the key path for cooperative channel closes and script path leaves for HTLC enforcement, revocation, and timeout conditions. When channels close cooperatively (the common case), no scripts are revealed. The script path activates only during force closes, encoding the channel's commitment transaction logic.

Hash Time-Locked Contracts

An HTLC can be structured as a two-leaf script tree: one leaf for the hash lock condition (receiver reveals a preimage to claim funds) and one leaf for the timelock refund (sender reclaims after expiry). Only the exercised branch appears on-chain.

Inheritance and Recovery Schemes

A user can set up a Taproot output where the key path handles day-to-day spending and a script leaf encodes a timelocked recovery path for a designated heir. If the primary key is lost or the owner becomes incapacitated, the heir can spend via the script path after the timelock expires. The heir's existence is never revealed unless the recovery path is actually used.

Discreet Log Contracts

DLCs can encode oracle-attested outcomes as script tree leaves. The key path handles cooperative settlement when both parties agree on the outcome, while script leaves enforce specific payouts based on oracle signatures.

Why It Matters

Script path spending makes Bitcoin contracts practical at scale. Before Taproot, every spending condition in a multisig or timelocked setup had to be revealed when any one condition was used, bloating transactions and leaking information. With script path spends, a wallet can embed dozens of spending conditions and only pay for the one it actually exercises.

This has direct implications for Layer 2 protocols. Systems like the Lightning Network and Spark use Taproot outputs with script trees that encode cooperative and non-cooperative spending paths. In the cooperative case, all parties sign via the key path, and the transaction looks like a simple single-signature payment. Only when disputes arise does the script path reveal the underlying contract logic, minimizing on-chain footprint and fees during normal operation.

For a deeper look at how Taproot and Schnorr signatures interact to enable these optimizations, see the Taproot and Schnorr Signatures Explained research article.

Risks and Considerations

Larger Witness Size

Script path spends are always more expensive than key path spends. The control block alone adds at least 33 bytes of witness data, and each level of Merkle depth adds another 32 bytes. Deep trees with many leaves can push the Merkle path to hundreds of bytes. Applications should structure their script trees so that the most likely fallback branches sit closest to the root, minimizing proof size when they are used.

Tree Design Complexity

Choosing the optimal tree structure requires estimating the probability of each spending path. An unbalanced (Huffman-style) tree places high-probability branches at shallower depths and low-probability recovery paths deeper. A poorly designed tree can make the most common script path unnecessarily expensive. Tools like Miniscript and output descriptors help manage this complexity.

Partial Information Leakage

While unused branches remain hidden, a script path spend does reveal the tree depth at the executed leaf. An observer seeing a Merkle path with five sibling hashes knows the tree is at least five levels deep, which provides a lower bound on the number of possible spending conditions. This is a minor leak compared to revealing the entire script, but it is not zero.

Backup and Recovery Burden

Wallets must store the full script tree (all leaves and their positions) to reconstruct Merkle proofs at spending time. Losing the tree structure means losing access to script path spending, even if the private keys are intact. This adds complexity to seed phrase backup strategies, as the seed alone does not encode the script tree.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.