Bitcoin custody mechanics

Opaque Signatures Break Bitcoin Script Vestibules

Updated 13 November 2026

That is an opaque signature. It is not a hidden custody policy. Bitcoin script can verify a proof whose contents reveal nothing about the signer, while the spending conditions remain fixed in the transaction. The danger is not that the box becomes invisible; it is that the people operating it mistake opacity for control.

The box still opens under public rules

Bitcoin custody mechanics often begin with a simple distinction: the hash commits to a message, while a signature demonstrates possession of a key. An opaque signature adds a third property. It allows a verifier to check that a signer authorised an action without learning which signer or which key material produced the proof.

That is useful when a signer must be hidden, when a policy separates authorisation from identity, or when an organisation wants to prove that an authorised party approved a spend without publishing a name attached to it. The transaction still exposes the script path, the witness data, the amount, and the output being spent. Opaque signatures therefore do not conceal the rule that governs the box. They conceal evidence about who was allowed to act under that rule.

The distinction matters because custody is not only about keeping coins inaccessible. It is about deciding who may authorise movement, how many parties must agree, what evidence is required, and what happens when a signer disappears, is compromised, or changes its policy. A proof can be opaque to an outside observer and perfectly clear to the script that checks it.

Bitcoin scripts verify conditions, not institutional intent. A verifier can accept a valid opaque proof and learn nothing about the human process that produced it. If the real custody arrangement depends on an undocumented convention, a separate governance system, or a promise that some party will monitor events, the script has not enforced those assumptions.

The warning follows from that gap. Never paste a seed into a watch-only field.

What opacity can and cannot hide

Opaque signatures are not the same as encrypted signatures. Encryption hides the contents from someone who cannot decrypt them. An opaque proof is designed to reveal only the fact needed for verification, not the underlying signer, witness, or authorisation detail. The verifier receives a credential that satisfies the script without receiving a readable transcript of the private decision.

That changes the meaning of a signature in the policy. In a conventional multisig arrangement, the script reveals the public keys and signatures that satisfy the threshold. The observer can inspect which participants appear to have authorised the spend, although that does not prove they acted voluntarily or understood the transaction. With opaque proofs, the observer may see that the threshold was met without learning which identities were involved.

There is no contradiction here. Bitcoin can prove authorisation against a programme rather than reveal a human-readable list of approvers. The script can enforce a one-of-one, a threshold, a timelock, or a branch-specific condition while preserving opacity about the evidence. What it cannot do is infer an organisation's internal rules from the existence of a valid proof.

The practical question is therefore not whether the proof is private. It is whether the policy is complete. If the script says that one opaque credential is enough, then one credential is enough. If the script says that three opaque credentials are required, then three are required. If the script says that a timelocked branch remains available after a deadline, that branch remains a possible exit even if operators prefer another path.

Use the opacity for what it proves. Do not use it as a substitute for signer roles, revocation decisions, backup procedures, or a tested recovery process.

Delegation without an identity map

Opaque signatures are most interesting when authorisation is delegated. A company can define a role such as treasury operator, risk approver, or recovery committee without exposing the individual occupying that role in every transaction. The script checks the credential and the policy still determines how many distinct roles must participate.

This can reduce linkability between a public Bitcoin address and a person or organisation. It can also make operational audits harder. A wallet that says two of three roles approved does not tell an analyst whether the roles were held by separate people, whether one person controlled two keys, or whether a role had been reassigned since the last policy review.

Delegation should therefore be documented outside the chain. The minimum record is not a seed and not a private key. It is a policy map: which role can authorise which branch, how role separation is maintained, which public commitments correspond to the opaque credentials, and who can revoke or replace a credential. Public commitments allow auditors to test continuity without requiring the chain to reveal the signer during every spend.

Opacity can also hide a stale authorisation process. A credential may remain cryptographically valid after a staff member leaves, after a key is exposed, or after a business unit changes its mandate. The script cannot know that the business has withdrawn permission unless the withdrawal is represented in the output's policy or in a mechanism that invalidates the credential.

That is where operational custody meets script policy. Treat roles as control points, not labels attached to keys. A role without a revocation route is a permanent capability. A role without an audit trail is an unmeasured risk.

Never paste a seed into a watch-only field.

Revocation becomes a policy problem

Ordinary Bitcoin multisig does not have a universal revocation message. Once a key has authorised a transaction, the transaction can be broadcast and confirmed. Changing the script for future outputs does not stop an already authorised spend. Revocation is consequently a matter of changing future control, deleting or rotating exposed credentials where possible, and preventing stale signers from participating in the next authorised set.

Opaque proofs do not automatically solve this. Hiding a signer's identity does not stop the signer from producing a valid proof later. If an exposed role can still satisfy the old script, the old script remains a live risk. The remedy is to move funds to outputs whose policy no longer relies on the compromised role, and to coordinate with other signers so that the migration cannot be blocked indefinitely.

There is a subtler issue: observers may not know which credential is compromised. If the chain does not reveal identities, an organisation must still have a reliable internal map from credentials to devices and people. Otherwise it cannot assess whether a compromised device can authorise a spend, cannot distinguish a legitimate proof from a replayed one, and cannot perform a clean credential rotation after an incident.

For custody purposes, opacity should be paired with explicit expiry, replacement, and migration rules. A credential that cannot be retired is not a temporary delegation. It is an enduring signing authority whose public visibility happens to be reduced.

That is the hard warning: conceal the signer if the policy requires it, but never conceal the authority from the people responsible for revoking it.

The verifier learns less, not everything

It is tempting to describe opaque signatures as a privacy upgrade for Bitcoin custody. That description is incomplete. They can improve privacy by reducing what is disclosed to outside observers, but they do not hide transaction amounts, output relationships, script conditions, timing, or the fact that a spend occurred.

They also do not make a wallet safer. A wallet that stores opaque signing credentials still faces device compromise, malicious software, supply-chain risk, operational error, and social engineering. The cryptographic proof may be sound while the process around it is unsafe.

Watch-only software adds another distinction. A watch-only field can inspect addresses, descriptors, balances, and transaction history. It should not be used as a place for seed material or any other input that could reveal spending authority. An opaque signature workflow can involve public descriptors, role identifiers, and policy metadata, but none of those should be confused with a backup secret.

For an organisation, the strongest design is often boring: separate the public policy from private credentials, assign each credential a named role, test the script against all reachable branches, and rehearse rotation. Opacity can be layered on top of that discipline. It cannot replace it.

Bitcoin script gives the box a rule. The custody system gives that rule an operator. If those two systems disagree, the script wins at spending time. Never paste a seed into a watch-only field.

A practical review checklist

Before accepting opaque signatures into a custody policy, ask what the script proves and what it deliberately leaves outside the transaction. Confirm whether the observer should learn the number of roles, the identity of roles, or neither. Then identify which facts are required for incident response but cannot safely be exposed publicly.

Next, test the paths. Exercise the normal spend, the timelocked fallback, the emergency branch, and the failure case where one role refuses to sign. Confirm that the intended number of distinct authorities is required, rather than merely the intended number of opaque proofs.

Finally, document credential retirement. State which device holds each role, which person or service can replace it, how replacement is coordinated, and how a compromised credential is prevented from satisfying future policies. Keep this record offline where appropriate, and do not treat a watch-only wallet as a credential vault.

The design question is not whether opacity is clever. It is whether the institution can still explain, prove, and revoke the authority that opens the box. If the answer is no, the proof is merely a harder-to-read key.

The custody conclusion

Opaque signatures change what Bitcoin reveals without changing the basic custody equation. The script verifies a credential against a rule. The rule may conceal identities while enforcing a threshold, a delay, or a constrained branch. The organisation remains responsible for the meaning of the roles behind the credential.

That makes opacity a privacy and delegation tool, not a recovery plan and not a revocation system. It can be valuable when public disclosure of approvers would be undesirable, but only if the policy map, signer separation, and migration process are maintained elsewhere.

Never paste a seed into a watch-only field.