What you will do
A Bitcoin signed message can show that a particular address's spending condition was satisfied for an exact piece of text. Verification checks three items together: the address, the message and the signature. Change any one of them and the result should fail.
This guide uses Sparrow Wallet 2.5.6, the latest published non-prerelease when checked on 9 November 2026. The official release was published on 29 October 2026. You will verify a public BIP 322 test vector, deliberately change the message to see a failure, then restore it and state the result narrowly.
No wallet is needed for verification. Do not import a seed, private key or wallet file. The example comes from the official BIP 322 basic test vectors, so it does not involve your address or funds.
Before you start
You need:
- Sparrow Wallet 2.5.6 from the official release page
- the address, exact message and signature supplied by the signer
- an offline note where you can keep those three items together
- a clear idea of what the signature is supposed to establish
Verification does not need a Bitcoin node connection and does not broadcast a transaction. BIP 322 constructs virtual transactions for script verification, but its missing input prevents them from being valid network spends.
Treat a signature as public data. Never paste a recovery phrase, private key, wallet password or hardware-wallet secret into the message dialog. Verification asks only for public inputs.
1. Check what you actually received
Before opening Sparrow, put the address, message and signature into three separate fields. Preserve capitalization, punctuation and line breaks. Do not correct spelling or change quotation marks.
Ask what the signer claims. A useful request is specific, dated and limited, for example: “I approve invoice 183 on 2026-11-09, nonce 7a31.” A vague message such as “I own this address” is weak even when its signature is valid. The cryptography checks the text, not whether the statement is complete, current or honest.
Also identify the signature format. BIP 322 version 2.1.0 defines visible prefixes for new encodings. A simple signature begins with smp, a full signature with ful, and a proof-of-funds packet with pof. Sparrow 2.5.6 exposes BIP322 (Simple) for supported single-signature SegWit and Taproot addresses. Do not assume that one wallet supports every script or every BIP 322 variant.
For this practice run, use these public values:
Address
bc1q9vza2e8x573nczrlzms0wvx3gsqjx7vavgkx0l
Message
Hello World
Signature
smpAkcwRAIgZRfIY3p7/DoVTty6YZbWS71bc5Vct9p9Fia83eRmw2QCICK/ENGfwLtptFluMGs2KsqoNSk89pO7F29zJLUx9a/sASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=
These values are published test data. Do not replace them with a private key from the same test-vector file.
2. Open Sparrow's verification dialog
In Sparrow, choose Tools > Sign/Verify Message. The released 2.5.6 menu definition places the action in the Tools menu and assigns the usual platform shortcut plus M.
Sparrow opens the dialog in verification-only mode when no unlocked signing wallet is selected. The released dialog source shows separate fields for Address, Message and Signature, plus format choices for standard legacy, BIP 137 and BIP 322 simple messages.
You do not need to open or unlock a wallet. If a wallet is already open, verification still uses the public values you enter. Do not click Sign during this procedure.
3. Enter the address and select the format
Paste the practice address into Address. Check the first and last six characters against the source:
- begins with
bc1q9v - ends with
vgkx0l
Sparrow validates the address before enabling verification. Select BIP322 (Simple). For a native SegWit address beginning with bc1q, Sparrow 2.5.6 allows both older message formats and BIP 322 simple, so the selected format is part of your record.
If the address came through a separate channel from the message, compare both copies. A valid signature for an attacker-substituted address proves the wrong thing perfectly.
4. Paste the exact message and signature
Paste Hello World into Message. The capital H and W, the single space and the absence of punctuation are all significant.
Paste the complete smp... string into Signature. It should remain one continuous line. Do not add Markdown fences or quotation marks.
There is one Sparrow-specific limit to understand. BIP 322 hashes the message bytes as supplied, but Sparrow 2.5.6 trims leading and trailing whitespace before its BIP 322 check. If the intended message begins or ends with spaces or newlines, Sparrow is not an exact-byte verifier for that case. Ask the signer for an unambiguous message or use a verifier that preserves those bytes.
5. Verify the public test vector
Click Verify. The expected result is:
Verification Succeeded
The signature verified against the message.
Sparrow first tries the legacy recovery formats and then, for supported address types and a non-empty signature, its BIP 322 verifier. A successful BIP 322 check selects BIP322 (Simple) in the dialog.
Record the software version, format, address, exact message, signature and result together. A screenshot without the text is not a durable verification record because a later reader cannot reconstruct the checked bytes.
6. Run a negative control
Change the message from Hello World to Hello world, with a lowercase w, and click Verify again.
The expected result is:
Verification Failed
The provided signature did not match the message for this address.
This negative control matters. It confirms that you are not merely looking at an old success dialog or verifying a different field. Restore Hello World and verify once more. The result should succeed again.
For a real request, you can also compare the address through a trusted second channel. Do not alter the real message just to make verification pass. A failure is information, not a formatting problem to guess around.
7. State the conclusion narrowly
A careful conclusion is:
Sparrow Wallet 2.5.6 verified this BIP 322 simple signature for this exact message and address on 9 November 2026.
Do not turn that into “this person owns the bitcoin.” Verification does not identify a human, prove exclusive control, show that the key is still controlled later, or establish the balance of a wallet. A custodian, shared wallet operator or compromised device may be able to produce a valid signature.
Our BIP 322 explainer covers those limits and the difference between simple, full and proof-of-funds formats.
Troubleshooting
Verify stays disabled: check that the address is complete and valid. Sparrow 2.5.6 only offers BIP 322 simple for the script types its implementation supports.
The signature fails: compare the address, message and signature character by character. Check capitalization, internal spaces, line breaks and the smp prefix. Do not keep editing the message until something passes.
The format changes after verification: Sparrow tries supported legacy formats before BIP 322. Record the format that is selected after a successful check and confirm it matches what the signer claimed.
Your message begins or ends with whitespace: Sparrow trims those edges in this release. Ask for a message without ambiguous boundary whitespace or use another current verifier whose exact-byte behavior you have tested.
A multisignature or ful/pof proof does not verify: this guide covers Sparrow's BIP 322 simple path for supported single-signature addresses. Use software that explicitly supports the script and variant. An unsupported result is not a valid proof.
Someone asks for your seed to verify: stop. Verification needs public inputs only. A request for a seed or private key is unrelated and unsafe.
What was and was not verified
The Sparrow 2.5.6 release, its released menu and message-verification implementation, BIP 322 version 2.1.0 and the official basic test vectors were checked on 9 November 2026.
A disposable Node.js fixture recomputed the BIP 322 tagged message hashes for the empty, Hello World and UTF-8 official vectors. It also confirmed that changing capitalization or adding a trailing newline changes the hash. Six expected checks and six executed checks passed. No secret keys, wallets, addresses belonging to a person, nodes, transactions or funds were used.
The Sparrow binary and graphical dialog were not executed in this cloud workspace. The click path and result text are described from the released 2.5.6 source, while the cryptographic fixture covers message hashing rather than full script or signature validation. The hand-authored SVG was rendered to a 1200 × 630 WebP and visually inspected; hosted CI must validate the committed SVG and production asset.
Verification is useful because it fails when the public inputs no longer match. Keep those inputs together, run a negative control and describe only what the successful check actually established.