Bitcoin custody mechanics

Opaque Signatures Break Script Vestibules

Updated 11 November 2026

That is an opaque signature boundary. It is not a missing key.

The blind branch

Bitcoin script can test whether a signature is valid, but ordinary signatures do not reveal which message was signed. A SIGHASH flag controls the commitment covered by the signature, but script still cannot read the covered transaction fields and compare them with an internal branch. The script sees a cryptographic result, not the data that produced it.

This distinction matters when a developer wants one output to represent several possible spending paths. If the script must choose a path before verifying, it may need separate branches for each possibility. Each branch can check a different signature commitment without the script learning why that commitment was selected.

The custody consequence is subtle. A valid signature can authorise spending while giving the script no programmable view of the policy that selected it. The key still controls the spend. The script is merely blind to the meaning outside the signature.

That is an opaque signature boundary. It is not a missing key.

Why branches multiply

Suppose a covenant-like construction compares the spending transaction with an earlier commitment. A script cannot simply ask what a signature covered. The output may therefore enumerate acceptable conditions and verify a signature under each condition. The witness can satisfy one branch while the others fail.

Segregating those checks can reduce ambiguity, but it also creates a larger validation surface. A covenant designer may want the script to bind directly to a specific transaction field, while a signature based design can only ask the validator to accept a signature over a commitment that the script cannot inspect.

Taproot script paths do not remove the boundary. A key path spend bypasses the script entirely. A script path spend enters a leaf whose execution can test signatures but still cannot parse an opaque signature. The same limitation therefore applies whether the spend is nested under an internal key or a script leaf.

Witness data can carry additional information, but adding information to the witness is not the same as proving that an opaque signature signed it. A signature that validates over one commitment does not attest to every adjacent witness byte.

A practical example is a branch intended for an administrator and another intended for a timelocked recovery path. If the administrator signature is checked under a commitment that script cannot inspect, the administrator branch verifies the signature but cannot independently prove that the relevant amount or destination matched the administrator's policy. The recovery branch may be checked separately, with the witness satisfying only the branch that applies. This arrangement does not make the signature fraudulent. It makes the relationship between the signature and the intended branch a matter for the signer and the wallet or coordinator to establish before signing.

The example also shows why adding a labelled witness element does not solve the underlying issue. A participant may include a destination identifier, a sequence value or a recovery label, but script has to compare that value with a commitment it can understand. Unless the label is covered by an explicit hash, or checked against a separately authorised value, it remains contextual information rather than a consensus-enforced fact.

The control flow cost

Multiple branches can create repeated validation work, failed execution paths and complex fee estimation. The transaction must provide enough witness material for the chosen branch to succeed, and script execution must still reject every disabled branch. A branch that looks redundant can still affect the maximum witness size or the amount of data relayed across the network.

There is also a policy risk. The author of the script, not the signer alone, determines which branches exist and what each branch checks. If several branches authorise materially different destinations under opaque commitments, users need to understand the whole construction rather than treating the signature as a self describing instruction.

This is why branch count alone is a poor security metric. Two simple branches may be easier to audit than one elaborate branch with ambiguous signature semantics. The hard warning is not that opaque signatures are weak cryptography. It is that a valid signature can conceal the policy context that led to it.

Reviewers should map every branch to a distinct spending condition and identify whether that condition is visible to script. A useful worksheet records the branch purpose, the public key or key expression used, the commitment that can be checked, the witness items required, and the failure condition. It should also record what the branch cannot establish. For example, a successful signature proves that the holder of a key authorised a particular commitment, but it may not reveal why that commitment was selected or whether it matched a business rule communicated outside Bitcoin.

That distinction matters when reviewing a transaction after it has been assembled. A wallet may display a destination and amount while the script checks only an opaque signature. Unless the displayed information is independently bound into the script's checks, the wallet's display is a trust assumption about the signing process. The same applies to automation: a coordinator can choose the right branch, but it cannot make an unreadable commitment readable merely by naming the branch in the witness.

Testing should cover both success and rejection cases. A successful spend demonstrates that one route can be satisfied, but it does not show that an unintended route is impossible. Reviewers should attempt to satisfy each disabled branch with valid-looking witness material and confirm that execution rejects it for a known reason. They should also test whether the policy explanation changes when the underlying commitment changes, while the visible witness structure remains similar. That is the practical symptom of opacity, and it should be recorded rather than hidden behind a familiar signature indicator.

What remains inspectable

Some mechanisms expose the information script needs. A pre committed hash can let script compare a digest, while an explicit data commitment can make the intended condition visible. These approaches alter the construction and may require the spending party to supply or reveal particular values. They do not create a general promise that a signature itself becomes script readable.

Hardware policy checks can add a human visible rule before signing, but they do not change what Bitcoin script learns. Likewise, a wallet interface can explain an opaque commitment before it is authorised, but that explanation is outside consensus. Consensus still sees only the script, witness and transaction structure.

The relevant audit question is therefore precise: which conditions can script distinguish, and which conditions remain encoded only in an opaque signature or in off chain policy? If the answer is unclear, the transaction may spend correctly yet communicate the wrong intent.

Consider a transaction intended to release funds only when an amount remains below a stated ceiling. One design signs a transaction commitment that incorporates the amount and asks script to verify the signature. The signature can be valid, but script cannot extract the amount from that commitment to compare it with the ceiling. A different design commits separately to the amount using a hash, places the preimage in the witness, and checks the hash against the script's expected value. The second design gives script a quantity it can inspect, at the cost of exposing that value and adding a distinct authorisation rule.

This does not make the second approach universally superior. Preimages may require careful management, and a commitment scheme introduces its own assumptions about how values are supplied. The practical benefit is narrower but important: disagreements can occur in consensus-visible checks rather than solely in a coordinator's interpretation. For every intended policy, an auditor should ask whether the rule is enforced by script, checked by the signing device, trusted from the wallet, or merely stated in documentation. These categories should not be conflated.

The custody warning

Opaque signatures do not by themselves transfer coins without authorisation. They complicate the relationship between authorisation and programmable intent. A signer must know what commitment is being approved, and a script designer must know which branches the signer believes are equivalent.

The warning becomes stronger when an opaque branch sits beside a simple branch with a familiar-looking destination. A user may reasonably assume that the script guarantees the visible destination, when it only guarantees that one of several opaque commitments was signed. Wallet labels, transaction annotations and coordinator messages can help a person understand the intended route, but they do not become part of consensus unless the script or another independently authorised mechanism checks them.

For operational safety, keep the authorisation and intent review as separate steps. First inspect the exact transaction, including every input, output, fee and locktime relevant to the policy. Then identify the branch that the witness activates and determine whether script can prove the relevant condition itself. Where script cannot inspect it, require the signing device or a trusted coordinator to enforce the rule, and make that dependency explicit in the review record. This preserves the key's custody function while preventing opacity from being mistaken for programmable certainty.

Never paste a seed into a watch-only field.