You signed. You broadcast. The transaction confirmed, and you closed the laptop feeling like the vault was shut tight. Except a researcher running a full node just learned something about your wallet's internal structure that you almost certainly didn't mean to share.
That's the quiet side effect of Taproot scriptpath spending. It's worth understanding precisely.
What Taproot Actually Hides (and What It Doesn't)
Taproot restructures how spending conditions are encoded. The core idea is elegant: a single output commits to both a key (the keypath) and a Merkle root of a script tree (the scriptpath). Spend via keypath, and the output looks identical to any other Taproot spend. One signature, nothing revealed. A passive observer sees a 32-byte x-only public key in the output and a Schnorr signature in the witness. Full stop.
Scriptpath is different. It handles the cases where the keypath isn't satisfied, or where you deliberately want to enforce a script condition: a timelock, a hash preimage, a multisig quorum. When you go that route, the witness must include the specific script leaf you're executing, plus a control block containing the Merkle proof connecting that leaf back to the output's commitment.
And that Merkle proof is precisely what leaks the depth.
The Merkle Branch as a Measuring Tape
A Tapscript Merkle tree works exactly like any binary Merkle tree. Leaves are individual scripts, hashed into 32-byte nodes. Pairs of nodes are hashed together up to the root. The control block carries the sibling hashes along the path from your leaf to the root.
Count the sibling hashes in the control block. That count is the depth of your leaf.
A leaf at depth 1 has one sibling hash: it sits directly beside the root. Depth 2 needs two sibling hashes. Depth 7 needs seven. The control block length is deterministic: 33 bytes of base data (version byte plus the internal public key) plus 32 bytes per level of depth. A control block of 97 bytes signals depth 2. A control block of 225 bytes signals depth 6.
Anyone watching the chain can do this arithmetic in under a second. No cryptography to break, no keys to guess. The structure is sitting right there in the open, as readable as a bus schedule.
Wallet developers typically arrange script trees with the most likely spending conditions near the top. Rational choice: shallower leaves cost fewer bytes in the witness, which means lower fees. So if your vault has three conditions (cooperative key, 2-of-3 multisig after 30 days, social recovery after 180 days), a sensible developer puts the cooperative key at depth 1, the multisig at depth 2, and the recovery path at depth 3.
When you spend via the 30-day multisig, you reveal depth 2. A chain analyst now knows your script tree has at least three leaves. They don't know what the other scripts say. But they know the tree is at least that tall, and they can make educated guesses about what kind of wallet produces trees of that shape.
A Concrete Example Worth Running Through
Call them Priya and Marcus. Both used the same open-source vault software to set up Taproot outputs in the same month. The software generates a four-leaf tree: immediate keypath at the top, then three script leaves at depths 1, 2, and 3.
Priya's funds are spent via keypath. Her transaction reveals nothing about the script tree. A researcher sees a standard Taproot keypath spend and learns exactly nothing about her internal conditions.
Marcus's keypath key was lost (a hardware wallet wipe, a story for another time). He spends via the depth-2 multisig leaf. His witness contains a control block of 97 bytes: 33 base bytes plus two 32-byte siblings. Any node operator can see the tree is at least depth 2. The specific software this vault uses is publicly documented as producing four-leaf trees with this exact depth structure. The researcher cross-references the control block length against known wallet fingerprints and, with reasonable confidence, attributes Marcus's output to that vault product.
No private keys compromised. No scripts decoded. Just geometry.
What People Get Wrong About This
The most common misconception is that Taproot's privacy is binary: either you spend via keypath and you're invisible, or you spend via scriptpath and you've revealed everything. I think this framing does real damage, because it makes people either falsely confident or unnecessarily fatalistic.
Scriptpath spending is not catastrophic. The scripts in the unexecuted leaves stay hidden. A seven-leaf tree that reveals one path exposes the depth of that path and the existence of at least that many siblings. The other six leaves' actual logic stays committed but unrevealed. That's a genuine, substantial privacy gain over the old P2SH model, where spending required revealing the entire redeem script upfront.
But the depth is always visible. Always. And depth is information.
In a world where wallet software ships with characteristic tree structures, a depth-3 leaf is suspicious in a two-condition wallet, and a depth-7 leaf suggests something exotic. Depth becomes a fingerprint. Wallet developers have known about this since BIP-341. The mitigation is deliberate tree balancing: arrange leaves so the most and least likely paths sit at similar depths, sacrificing some fee efficiency to flatten the fingerprint.
Few wallets actually do this today. Partly because it costs users money in the common case. Partly because the chain-surveillance implications feel abstract until you see the control block arithmetic laid out plainly. I find that second reason less forgivable than the first.
There's also a more aggressive approach: padding the tree with dummy leaves (scripts that are valid but unspendable, or simple `OP_RETURN` constructions). This forces all trees to a uniform depth regardless of actual complexity, making control block length uninformative. The cost is a slightly larger commitment at output creation time, not at spend time. A worthwhile trade for high-value vaults. A nuisance for everyday use.
So ask yourself: do you actually know what depth your wallet's script leaves sit at? Most people don't, because the software never surfaces it.
Taproot scriptpath spending is far more private than what came before it, and the depth leak is real but bounded. The question isn't whether to use Taproot. It's whether the wallet software building your script tree is thinking carefully about what shape that tree leaves behind on-chain. Check your control block lengths before you assume you're invisible.