A Bitcoin message signature can be useful when someone needs to connect a statement to a particular receiving address. It can also become misleading the moment a green verification result gets translated into “this person owns these coins.” Those are different claims.
The practical question is narrower: does this proof validate for this exact message and the address we intended to check? Understanding that boundary makes message signing more useful, especially when wallets support different formats.
Start with the address you already trust
Bitcoin Core’s verification interface takes three inputs: an address, a signature and a message. The address is part of the question. A signature that validates against an address supplied by an unknown sender does not establish a connection to a previously trusted person.
Imagine someone impersonating a seller. They provide their own address and a perfectly valid signature saying they are the seller. The mathematics can work while the impersonation remains intact. The missing evidence is the link between the seller and that address.
That is why a useful verification process starts with an independently established address or a trusted communication channel. Treat “the signature matches” and “the address belongs to the person I mean” as separate checks. This is an inference about authentication, not an additional property the signature supplies.
A signature also does not make the signed words true. Bitcoin Core’s message-verification warning cautions against reading extra meaning into a signed statement and explicitly says it cannot establish who sent a transaction.
Why the same proof may fail in another wallet
The traditional signmessage format uses a compact ECDSA signature. Bitcoin Core’s published legacy verification code recovers a public key and checks it against a P2PKH address. That routine is not a universal verifier for every Bitcoin spending condition.
BIP 137 describes extensions that distinguish legacy and certain single-key SegWit address formats. Those extensions explain why some wallets handle more cases than an older verifier. They do not turn every feature named “Sign Message” into the same interoperable protocol.
Product support needs its own check. For example, Trezor Suite’s current guide says Sign & Verify is unavailable for Taproot accounts. That is a documented product limitation, not evidence that Taproot can never support message proofs. These examples were checked in documentation and source code; no live messages were tested for this article.
If verification fails, first check the format and supported account type. A mismatch is a reason to investigate, rather than an immediate verdict that the sender lied.
What BIP 322 changes
As checked on October 13, 2026, BIP 322 is marked Complete, version 2.0.0. It defines a generic, script-based approach. Its simple format covers native SegWit cases, including Taproot, within specified limits; the full format covers broader scripts and timelocks. A separate proof-of-funds variant addresses selected transaction outputs. The current formats use smp, ful and pof prefixes respectively.
“Key control” is convenient shorthand, but generic verification actually checks satisfaction of the specified script. The BIP also warns that legacy signatures lack a public-key commitment and are not a general proof of secret-key knowledge. No message protocol establishes lasting control of funds: access can change, and someone can sign for another party without granting spending authority.
The specification’s status does not guarantee that two installed wallets implement the same version or variants. Confirm compatibility before relying on a proof, and treat an inconclusive result as unresolved.
Properly constructed BIP 322 proofs use transaction-shaped structures that cannot move real bitcoin. COLDCARD’s implementation documentation explains the enforced restrictions and distinguishes an ordinary message proof from its reserves workflow. That protection depends on recognizing and validating the format; a request labeled “verification” deserves no automatic trust.
A safer way to assess a proof
For a consequential check, use this short review:
- Preserve the original message, signature and address together. Bitcoin Core’s verification warning calls out spaces, tabs and line breaks: seemingly harmless edits can change what is being checked.
- Establish the intended address independently. Do not let an unfamiliar verification website supply both the evidence and the identity claim.
- When requesting fresh evidence, make the challenge specific to the recipient and purpose, with a new unpredictable reference and a short validity window. This is a practical defense against reuse, not a timestamping guarantee.
- Read the entire statement. Reject wording that grants broader authority than the task requires. Core’s signing interface specifically warns about vague statements and phishing.
- Use a trusted verifier with documented format support. Verification should not require surrendering a seed phrase or private key. Keep any request for secret material outside the verification process.
A sensible conclusion is that a particular proof passed a particular check. Legal ownership, exclusive custody, a person’s identity and the truth of their promises require evidence beyond that result. Keeping those questions separate is what lets a message signature do its actual job.