A green checkmark next to a Bitcoin signed message can look like proof of several things at once. It is not. A successful check supports one narrow conclusion: the supplied signature satisfied the verification rules for the supplied message and address, subject to whatever time conditions were reported. Who the signer is, whether they still hold the funds, and whether they can spend them are separate questions that need separate evidence.
Three outcomes, not two
BIP322, the modern standard for generic signed messages, does not reduce verification to a binary pass or fail. It defines invalid, inconclusive, and valid states. A failed required check is invalid. A script the validator cannot check, or a failure of a rule the specification marks as upgradeable, yields inconclusive. A valid result carries a time condition drawn from a virtual transaction’s locktime and the sequence of its first input, which reports how fresh the proof is rather than when a person signed it.
The message is hashed exactly as written
The fastest way to break a verification is to alter the challenge. BIP322 hashes the message as supplied, with no length prefix and no null terminator, using a BIP340-style tagged hash under the label BIP0322-signed-message. Re-typing or silently editing the message before checking produces a different hash and a meaningless result. The older BIP137 compact-ECDSA format packs recovery information and address-type conventions into a single header byte, so a verifier must match the exact format the signer produced instead of treating the encodings as interchangeable.
Proof of funds has its own limits
The proof-of-funds variant lets a signer demonstrate control over a set of UTXOs they choose themselves, and it does not establish completeness. Verifying it requires the current UTXO set, which is why an offline checker can confirm the cryptographic validity of the cited inputs without confirming that those outputs still exist and remain unspent. The result answers “do I control these outputs,” not “do I control everything” or “am I solvent.”
Do not turn a signature request into a payment
BIP322 builds a virtual transaction around an invalid input, so the structure cannot be broadcast or spent on the real network. That is deliberate, but it also means a signature request must never become an instruction to approve transaction data, move coins, or hand over seed words or private keys. The specification is explicit that a key holder can sign a message on someone else’s behalf while refusing to sign actual transactions, and that no message-signing scheme can prove who sent a prior transaction.
The practical habit is to write down the claim a proof must support before requesting one. If a result is inconclusive, find a capable verifier. If current outputs matter, add a chain-state check. If identity or solvency is the real question, ask for evidence aimed at that question directly. A signed message will not answer it for you.
Adapted from What Does a Bitcoin Signed Message Actually Prove?.