Taproot, and the privacy of a script you never reveal

A Taproot output commits to a single public key, and that key can be spent in one of two ways. The key path is the simple one: a signature against the committed key, exactly as an ordinary payment would be spent. The script path is the alternative: the output also commits to the root of a Merkle tree of scripts, and a spender can reveal one leaf of that tree together with the proof that it belongs to the committed root, then satisfy that leaf's condition.

The design decision that makes this useful is that the key used for the key path is not a separate key. It is constructed so that the key path remains available even when a script tree exists, and the participants can agree in advance that the key path is the normal route. A cooperative spend therefore uses the key path and reveals nothing about the tree. Only when cooperation fails — a signer is unavailable, a timelock has not expired, a dispute has arisen — does anyone reveal a script leaf, and even then only the one leaf that is being used.

The privacy gain is precise and worth stating carefully. Taproot does not hide that a transaction occurred, and it does not hide the amounts or the outputs. What it hides is the shape of the spending condition. Before Taproot, a multi-signature arrangement was visible on-chain as a multi-signature script, and an observer could count the keys and infer something about the arrangement. After Taproot, a cooperative multi-signature spend is a single signature against a single key, and it is indistinguishable from a payment made by one person with one key. The observer learns nothing, because there is nothing to learn from.

BIP 342 defines the script semantics for Taproot spends, and it makes several changes to the language that are easy to overlook and important in practice. Signature checking operations are upgraded to verify Schnorr signatures, and the rules about which signature operations are permitted are tightened. The changes are not cosmetic: they are what allow a script leaf to be written with the assumption that a signature check means what it says.

The script tree itself is a Merkle tree, and the commitment is to its root. A spender reveals the leaf being used and the hashes needed to reconstruct the path to the root, and a verifier checks that the reconstruction matches the committed value. The tree can hold as many branches as the participants want, and the cost of a spend depends on the depth of the leaf used rather than on the total size of the tree. An arrangement with a dozen possible outcomes costs the same to spend through its most likely branch as an arrangement with two.

The combination of the two paths is what gives Taproot its character. The common case is cheap and private, and the uncommon cases remain available without being advertised. The Script page covers the language a leaf is written in, and the address types page covers the bech32m encoding a Taproot address uses.