A Taproot output can be spent through a key path or a script path. The choice changes what appears on-chain and what the spender must reveal.
Both routes are part of Bitcoin’s Taproot rules in BIP 341. The output itself commits to a public key and, optionally, a tree of scripts. When the coins move, the witness shows either a signature for the tweaked output key or enough information to prove that one committed script was satisfied.
The output hides the choice until it is spent
A pay-to-Taproot output uses a version 1 witness program containing a 32-byte x-only public key. That public key is not necessarily the wallet’s original internal key.
BIP 341 defines the output key as a tweak of an internal key. The tweak can also commit to a Merkle root representing a tree of possible scripts. This construction joins two ideas:
- cooperative spending can look like a single signature under the output key;
- fallback conditions can remain hidden unless one of them is actually used.
An observer looking only at an unspent Taproot output cannot tell whether a script tree exists. That ambiguity is intentional. A wallet may have only a key path, or it may have recovery, multisignature or time-based script leaves behind the same output form.
The Bitcoin address types explainer covers how a bc1p destination identifies Taproot at the address level. It cannot tell you which spending route will later be used.
Key-path spending: one signature under the output key
A key-path spend is the compact route. In the ordinary case, the witness contains a Schnorr signature for the Taproot output key. BIP 341’s validation rules treat a witness with exactly one element as a key-path spend.
The signature might come from one private key, but that is not the only possible setup. Several participants can use an off-chain key-aggregation protocol to cooperate on one signature. On-chain, the result can still look like a single-key spend. The chain does not prove how many devices or people took part in producing it.
This gives the key path two practical advantages.
First, it uses less witness data than revealing a script and its proof. That normally means a lower transaction weight for the input.
Second, it reveals less policy information. A cooperative multisignature arrangement, for example, does not have to publish the participants’ keys or threshold as an explicit script when everyone follows the key-path protocol.
The privacy claim needs a limit: a key-path spend hides the unused script policy at the protocol level, but transaction amounts, timing, address reuse, change selection and external data can still link activity. Taproot does not make the whole transaction private.
Script-path spending: reveal one leaf and prove it belongs
A script-path spend uses a committed script. Its witness includes the stack elements needed by that script, followed by the script itself and a control block.
The control block carries the internal key plus the information needed to reconstruct the relevant Merkle path. A validator hashes the revealed script into a leaf, combines it with the supplied branch hashes and checks that the resulting commitment produces the output key. If the proof matches, the script executes under Taproot’s script rules.
Only the executed leaf and its Merkle path are exposed. Sibling scripts stay represented by hashes. That is a significant change from older patterns that could reveal a larger policy.
Imagine a wallet with three intended routes:
- all operators cooperate through the key path;
- a recovery key can spend after a delay;
- a separate emergency committee can spend under a different condition.
A normal cooperative spend can reveal only a signature. If the delayed recovery route is needed, that leaf and its branch become public, while the emergency leaf can remain hidden.
The script path therefore costs more data and discloses more than the key path, but it provides an enforceable fallback when the cooperative route is unavailable.
What the witness lets an observer infer
The distinction is visible once the output is spent.
A single-element witness identifies the key path under BIP 341’s validation structure. A script-path witness exposes the selected script, its arguments and the control block. An analyst may learn which keys or locktime conditions were used and may infer something about the size or depth of the hidden tree from the Merkle proof.
That does not reveal every branch. A proof shows sibling hashes, not the contents behind them. It also does not automatically identify the people who control the keys. Those conclusions require evidence beyond the script.
Wallet designers can reduce unnecessary disclosure by placing likely paths at shallower positions in the script tree. A shorter Merkle path needs fewer hashes in the control block. The exact savings depend on the tree and the script, so a wallet should calculate the input weight instead of assuming every script-path spend has the same cost.
Why wallets usually prefer the key path
When all required signers are available and the signing protocol succeeds, the key path is normally the efficient choice. It minimizes on-chain data and keeps the fallback policy private.
That preference is not absolute. A wallet may deliberately use a script path because its policy cannot be expressed through the available cooperative signing setup, because a signer is unavailable, or because a timeout or recovery condition has become active.
The choice is also made by wallet software. A user sending bitcoin does not select “key path” or “script path” from the address. The spending wallet has to know the internal key, any script tree, the available signing material and the conditions that are currently satisfied.
Implementation checks that prevent expensive mistakes
A Taproot wallet should preserve more than the address and a private key.
It needs the internal key, the script tree or a reproducible descriptor, and the derivation data required to rebuild control blocks. Losing the script-tree information can make a valid recovery path practically unusable even when the corresponding key still exists.
Before funding a policy, verify that the wallet can:
- reproduce the same output key from the internal key and script commitment;
- generate a valid control block for every intended recovery leaf;
- estimate transaction weight for both key-path and script-path spends;
- recognize the locktime or sequence conditions used by each leaf;
- test recovery with the same descriptor and backup process used in production.
For an overview of how inputs and witnesses fit into a transaction, see Bitcoin UTXOs explained.
