Script path spend

Script path spends are the fallback route out of a Taproot output, used when the cooperative signature everyone hoped for never arrived. The proof rides in a control block of 33 bytes plus 32 more for every level of the tree, and BIP-341 caps that tree at 128 levels. Taking this route publishes the branch you used, so the one condition you actually relied on stops being private.

How it works

A node validating a script path spend reads the witness stack backwards, because the last element does most of the work.

That last element is the control block, and its length is checked before anything else. It has to be exactly 33 + 32m bytes for a whole number m between 0 and 128, and any other length fails outright. BIP-341 sets the ceiling at 128 because an optimally packed tree goes deeper only for a leaf with under a 1 in 2^128 chance of being used.

The first byte carries two unrelated things. Mask it with 0xfe and you have the leaf version, 0xc0 for the tapscript rules; the bit you masked away is the parity of the Y coordinate of the output key, present so the spend can be batch verified. The next 32 bytes are the internal public key, the one that would have signed a cooperative spend; everything after is the merkle path, 32 bytes per level.

The node then rebuilds the commitment. It hashes the leaf version with the revealed script into a tapleaf hash and folds in each path element in turn. Direction is never transmitted: the two 32-byte values at each step are sorted lexicographically before hashing, so the comparison decides the order and no direction bit is sent. The root and the internal key produce a tweak, and the tweaked key has to equal the 32 bytes sitting in the address, parity bit included, before the script is allowed to run.

One byte can change everything before it. If the witness holds at least two elements and the last begins with 0x50, that element is stripped as the annex before validation starts. BIP-341 defines no meaning for it and warns that including one may lead to "PERMANENT FUND LOSS".

Where you see it

A script path spend is recognizable on a block explorer as a Taproot input whose witness, annex aside, holds more than one element.

BIP-341's own worked example is a tree of five scripts, A through E. Spending with script D publishes D, plus a control block holding the internal key and three hashes: C, E, and the combined hash of A and B. That control block is 129 bytes for a five-condition contract, and the other four scripts are never published.

The proof also gives something away. BIP-341's security section notes that the depth of the revealed leaf leaks the minimum depth of the tree, which "suggests specific wallet software that created the output and helps clustering". The defense BIP-341 suggests is deviating from the tree the leaf probabilities would otherwise make optimal.

The same section is blunt about key reuse. Keys have to be fresh across every leaf, not only the one you spent, because a repeated branch reappears as a repeated hash in a later proof, and leaves sharing keys make an unrevealed script cheap to brute force.

Script path spend vs Tapscript

A script path spend is the route; tapscript is the language spoken at the end of it. BIP-341 defines everything up to the moment execution starts: the control block, the sorted merkle fold, the tweak check, the parity bit. What runs afterwards is decided by the leaf version.

Only 0xc0 currently means tapscript. A leaf carrying any other version is not an error, because BIP-341 requires execution to succeed for unknown leaf versions. That is the hook letting a later soft fork define a different script language inside the same bc1p address format, which makes script path spending the durable half of the pair.