Key Path vs Script Path Spend

Key path versus script path spend describes the two ways every Taproot output can be unlocked, with the choice made at spending time. The key path is the cheap, private default: a single signature and nothing else. The script path is the fallback for richer conditions: reveal one committed script and satisfy it. This duality is the heart of Taproot's design — it lets complex contracts look like ordinary payments on-chain whenever everyone cooperates, and only pay the cost of complexity when cooperation fails.

The design is best understood as the payoff of a decade-long argument about how Bitcoin should hide complexity. Earlier script-hiding schemes made contracts cheaper but still betrayed, at spend time, that a contract existed at all; the taproot insight was that the cooperative case — which is also the overwhelmingly common case — could be made literally indistinguishable from the simplest possible payment, while every contingency stays committed but invisible behind the same key. The name itself is the metaphor: a taproot is the single main root from which lesser branches spring. One key on-chain, a whole tree of conditions beneath it, and the tree surfaces only if the root cannot act.

How the output commits to both

A Taproot output contains a single output key, which is the internal key tweaked by a commitment to a Merkle tree of scripts (the taptree). That one tweak binds both spending routes together: the internal key's holder(s) can sign directly, and any leaf script in the tree can be proven to belong to the output. Nothing about the output reveals whether a script tree even exists — an output with elaborate fallback conditions is byte-identical in form to one with none.

Key path spend: the happy path

A key-path spend provides exactly one witness element: a Schnorr signature valid for the output key. It is the smallest possible Taproot spend — cheapest in fees — and it reveals nothing about any alternative conditions that might exist behind the key. The quiet superpower is key aggregation: because Schnorr signatures compose, the internal key can be an aggregate of many participants' keys, and a signature produced collaboratively (commonly via MuSig2) is indistinguishable from one signer's. A 3-of-3 multisig vault, a Lightning channel close, and a single-key hot-wallet payment all look identical on-chain when they use the key path.

Script path spend: the fallback

When the cooperative key cannot or should not sign — a co-signer disappears, a timelock recovery must fire, a dispute needs enforcement — the spender uses the script path. The witness then reveals three things: one leaf script from the committed tree, the stack items that satisfy that script under Bitcoin Script rules, and a control block containing the internal key and the Merkle path proving the leaf belongs to the tree. Crucially, only the executed branch is disclosed. If your vault has five recovery conditions and you use one, the other four never appear on-chain — observers learn that some tree existed and that this leaf was in it, nothing more.

Why the split matters

The privacy win is structural rather than optional. An outside observer cannot tell whether a key-path spend came from one signer or a federation of twenty, and cannot enumerate unused script branches, so the anonymity set of "plain-looking Taproot spends" covers everything from simple payments to elaborate contracts. The economics reinforce the privacy: the cooperative path is also the cheapest path, so incentives push everyone toward the private outcome by default. For self-custody design, the practical rule of thumb is to put the expected, cooperative case on the key path and reserve the script tree for the failure modes you hope never to use — inheritance timelocks, degraded-quorum recovery, emergency sweeps. When designed that way, your contingency planning costs you nothing in privacy or fees until the day you actually need it.