Taproot evidence: a visible key does not reveal every spend path
A visible Taproot output key does not reveal the complete set of conditions under which the output can be spent. A disclosed timelocked script can be genuine while a different authorized route exists. Before calling funds universally locked for a period, distinguish the condition on one demonstrated path from the policy covering every possible path.
The research deliverable is a path-evidence register. It names what was observed at funding, what was revealed during a spend and what additional disclosure would be needed to assess a broader control claim. It does not infer a signer count from an address format.
Begin with the exact claim about control
Translate a statement such as “treasury funds require two approvals and a thirty-block delay” into separate predicates. Does it concern a particular recovery path, the ordinary operational path, all outputs in an address set or every possible spend of one specified output? Those are different statements.
BIP 341’s Motivation and Constructing and spending Taproot outputs sections explain the limited disclosure design and the distinction between key-path and script-path spending. A script-path witness supplies the script and control-block material needed for its commitment checks. That does not publish the contents of every sibling script hidden behind the remaining hashes.
Save the funding outpoint, scriptPubKey, output key and selected network. When a spending transaction exists, save the raw witness and identify the path according to the applicable rules. A human label such as multisig is not evidence that the observed spend used a script requiring the displayed number of signatures.
Organize the evidence by stage
At funding, the output commits to its key and any relevant script-tree construction without exposing every underlying condition. The register should therefore mark complete script policy unknown unless further material supports it.
For a key-path spend, the public witness supports checking the relevant key-path authorization. It does not reveal whether the output key represents one person’s key, an aggregation process or some other offchain arrangement. It also does not enumerate unused scripts.
For a script-path spend, parse the actual revealed script and control block, check its connection to the funded output and evaluate the path’s requirements. Separate “this condition was used” from “no other condition could have been used.” The latter needs more evidence.
Retain unrecognized witness structures rather than forcing them into a familiar template. Parser failure is an analytical limit. It should trigger a narrower conclusion or specialist review, not a claim that the funds have no restrictions.
A hypothetical two-script treasury
Assume a fictional Bitcoin-compatible environment and an invented output funded at height 5000. The example’s constructor has two script leaves: L1 requires the stipulated two-signature authorization and a relative eligibility predicate H ≥ 5030; L2 is a recovery path with a different authorization and predicate H ≥ 5100. An available key-path authorization is another possibility in this constructed example.
These height predicates are assumptions for the illustration. They are not a shortcut for decoding every real sequence field or applying every consensus timing rule.
The public project note shows only L1 and says its thirty-block condition applies to the entire output. Compare the evidence at three stages:
| Evidence available | Supported observation | Unsupported extension |
|---|---|---|
| Funding output only | Specific output key exists | Exactly two people control all spending |
| L1 disclosure with a verified commitment path | L1 is committed to this output | L1 is the only available path |
| A valid spend using L1 at H = 5040 | That spend satisfies its applicable path rules | Every possible earlier spend was impossible |
| A valid key-path spend at H = 5005 in an alternative history | The example’s key authorization can spend then | The thirty-block condition applies to that route |
The waiting arithmetic for L1 is 5040 − 5000 = 40 blocks, which satisfies the stipulated minimum of thirty. A key-path spend at 5005 occurs five blocks after funding. That does not break L1’s timelock; it uses a different route whose authorization must be assessed separately.
The L1 spend and earlier key-path spend are alternative histories of the same output. They cannot both consume that outpoint on one valid selected chain. The comparison tests a claim about possible controls; it does not add two completed treasury withdrawals.
Reconstruct the commitment, then assess completeness
Where script-path evidence exists, preserve the internal key, leaf version, revealed script and ordered sibling hashes from the control block. Use a verifier implementing the relevant Taproot rules to connect that material to the output key, including the required key checks. Do not replace the process with a visual comparison of script names.
The tree path authenticates the revealed leaf relative to the output construction. A sibling hash commits to hidden material without disclosing that material’s text or conditions. Seeing one such hash is not evidence that its leaf has the same threshold or delay as L1.
If the project supplies a purported complete tree, reconstruct its commitment from the supplied leaves and compare it with the funded output using the disclosed internal key. Ask whether the package is complete under that construction, not simply whether every listed script looks restrictive. Preserve the exact package version and who supplied it.
Even a fully supplied tree does not by itself settle key-path control. A claim that the key path is intentionally unusable needs an explanation of the internal-key construction and its assumptions. A public point with no disclosed private key is not automatically proof that nobody knows a corresponding secret.
A different boundary: seeing a script spend does not prove necessity
An operator may choose a script route even if another authorized route was available. Consequently a script-path spend is not proof that the key path was impossible at the time. It proves a path was used under the applicable verification, while alternative-control claims remain separate.
Likewise, a thirty-block condition can be a fallback safeguard rather than the normal release rule. Read the project’s operational claim carefully. A truthful statement about a recovery mechanism becomes misleading only when extended to all spending without support.
For an entity with many outputs, inspect coverage. One correctly audited script path does not establish a universal policy for all treasury UTXOs. Record which outpoints share the verified construction and which remain unexamined, rather than generalizing from a single example.
What would change the research conclusion?
A newly revealed leaf can add a known alternative route. A later spend can show which route was actually used. A corrected full-tree package can repair an earlier commitment mismatch. None of those changes should be silently retrofitted into what a public observer knew before the disclosure.
If two documents claim incompatible internal keys or trees for one funded output, preserve both and attempt the commitment checks. Matching the actual output is a concrete way to narrow the conflict. A missing package should remain a missing package, not be reconstructed from a marketing diagram.
Distinguish a cryptographic match from the organizational question. Shared access to signing devices, custody agreements and beneficial control may remain unknown even when the chain-level condition is clear. Count public conditions, not assumed independent decision makers.
For a quantity-level claim, avoid assigning one blanket lock label to an address. Suppose two outputs each contain 5 BTC, but only the first has a complete checked policy package and the second has only its public funding key. The covered amount is 5 of the nominal 10 BTC. That coverage fraction is not a safety probability, and it cannot establish a common thirty-block restriction on both outputs.
An actionable path register
| Action | Evidence to retain | Maximum justified statement |
|---|---|---|
| Fix output identity | Network, funding outpoint and output key | This is the output under review |
| Parse a real spend | Transaction bytes, witness and chosen chain | This path was used in this history |
| Verify a revealed leaf | Script, control block and verifier result | This leaf belongs to the output construction |
| Decode its restrictions | Keys, signature rules and timing predicates | These conditions apply to this path |
| Assess alternatives | Complete-tree material and key-construction evidence | Broader policy only within verified coverage |
| Compare the public claim | Exact wording, date and covered outpoints | Supported scope and unresolved extensions |
Release a statement that distinguishes demonstrated restrictions from unknown alternatives. For example, one committed recovery script requires the stated delay, while the evidence reviewed does not establish that every route or every treasury output has that delay. This conclusion is more precise than treating either a familiar address type or one restrictive leaf as a complete control audit.
FAQ
Does a Taproot address prove a particular multisignature threshold?
No. The visible output key does not enumerate the offchain participants or all script alternatives.
Does observing a delayed script spend prove earlier spending was impossible?
No. It shows the used path met its rules. A claim about every alternative requires additional evidence about the tree and key path.