Taproot changed what a Bitcoin transaction reveals. Before it, spending from most address types published the full conditions that authorized the coins. Taproot splits spending into two routes, and each one leaves a different amount of information on chain. For anyone reviewing a wallet’s disclosure policy, the difference between those routes is the whole point.
The key path is the quiet route. A single Schnorr signature, checked against the output key, is the only thing published. The spend does not say whether a script path was ever permitted, how many participants authorized the payment, or what recovery options existed. Because keys and signatures can be aggregated, one valid signature is not proof of one signer. A three-of-five wallet and a solo holder can look identical at the key path.
The script path is the louder route. Spending through a committed script publishes the selected script, its satisfaction data, and a control block that proves the output committed to that script. That control block carries the internal public key, the leaf version, and the Merkle-path hashes needed to verify the commitment. Leaf scripts that were not used stay out of the witness. What is exposed is the chosen leaf, not necessarily the whole policy.
The distinction has a practical edge that many wallets gloss over. A script leaf is a committed script, not an execution branch inside one. If a single leaf holds two conditional authorization paths, spending through either reveals the entire leaf, including the code of the branch that was not taken. Splitting the alternatives into separate leaves keeps the unused script off chain. BIP-341 states this directly: a revealed script’s depth exposes structure that helps observers fingerprint and cluster wallets, and it recommends distinct key sets across leaves to raise leaf entropy.
Script-based multisig makes the same point. Under BIP-342, a CHECKSIGADD script that lists several public keys publishes all of those keys, even when only a subset supplies signatures. Different constructions can authorize the same spend while disclosing different information, so a reviewer should inspect the actual selected script rather than assume every arrangement labeled “multisig” looks the same on chain.
Aggregation follows the same logic. BIP-340’s Schnorr standard provides the building block for interactive schemes that combine public keys and jointly produce a signature, but it does not automatically aggregate a wallet’s keys or signatures. The wallet has to implement it, and BIP-341 explicitly leaves key aggregation outside its own scope.
None of this is an anonymity guarantee. Taproot does not hide transaction amounts or the graph linking inputs to outputs. What it controls is how much of your policy logic a particular spend puts on chain. “Unused scripts remain undisclosed” means they need not be published, not that their contents are impossible to infer.
The practical discipline is to treat disclosure and readiness as separate questions. A hidden recovery leaf that never appears on chain says nothing about whether the signers, software, and policy information needed to use it are actually available. Before trusting a wallet policy, review it route by route: what does each spend publish, which sensitive alternatives sit in separate leaves versus inside one script, and can every intended route actually be executed?
Source: BTCUSA.