Bitcoin Core verifymessage RPC: Exact-Message Authentication Guide

This guide explains Bitcoin Core verifymessage RPC in plain English. It shows what the command does, what its result means and what it cannot prove.

Three bound inputs

Treat address, signature and message as one immutable challenge record. Validate lengths and encoding before calling the RPC, but preserve exact bytes. Substituting a normalised message, another address presentation or a repaired base64 string changes the evidence and must fail rather than silently continue.

Exact message review

Canonicalise the challenge before it reaches the signer, not during verification. Specify UTF-8, line endings and visible whitespace. Include the relying service, account, requested action and human-readable consequence so the signer can understand what possession of the final signature will authorise.

Replay resistance

Include a cryptographically random nonce, issuance time and short expiry and mark each challenge consumed after one successful decision. Bind it to the authenticated session and relying party. A valid signature over a generic phrase remains replayable anywhere that accepts the same phrase.

Boolean and errors

False is a normal verification failure and should not reveal which internal check was closest to passing. Distinguish malformed input or RPC error from a valid false response in protected logs, while presenting a uniform failure to callers to reduce probing and information leakage.

Address-method scope

The historical method is address-message verification, not a general proof for arbitrary descriptors, scripts or multisignature policies. Confirm compatibility with the signer method and deployed node version. Do not reinterpret unsupported script forms as negative identity evidence.

Identity boundary

A true result proves control of a signing key for this challenge. It does not establish who the controller is, whether they may represent a company or whether funds are currently controlled. Combine it with authenticated account and contractual checks where those claims matter.

How specialists test it

Operators test the command on a non-production node first. They check a normal reply, an invalid request, a timeout and a restart. This shows what the response means and prevents one local result from being mistaken for a network-wide outcome.

Conclusion

verifymessage is useful for a narrow, exact-byte key-control challenge. Authentication remains safe only when the challenge is readable, fresh, single-use and tied to an independently authenticated business context.