Understand Bitcoin descriptor checksums, what they protect during backup and import, and why a valid checksum cannot authenticate a wallet policy.
A small change can describe different locks
An output descriptor is text, but its contents determine scripts. Changing a key, a path or a wrapper can produce a different set of addresses. A backup that looks almost right may therefore restore an empty or unrelated wallet.
BIP 380 defines an optional checksum suffix introduced by #. Its purpose is error detection when descriptor text is entered, stored or transferred. Applications may require the checksum even though the general syntax permits expressions without it.
What a valid checksum establishes
A checksum tests whether the expression and its suffix agree under the specified encoding. It is useful for detecting accidental edits, truncation and transcription mistakes. It is not a secret, a signature or a certificate issued by a wallet provider.
Someone who intentionally substitutes a descriptor can calculate a matching checksum for the substituted text. That descriptor may parse correctly and still direct payments to scripts you did not intend to use. A green checksum result is one check, not the entire receiving-address verification process.
Two checks before accepting a backup
You import a public descriptor from a saved backup into compatible software. First, verify its syntax and checksum. Next, derive several address indices and compare them with addresses independently recorded from your original wallet. A mismatch is a reason to investigate the wrapper, path, network or backup—not a reason to send funds as a test.
Do not repair a backup by guessing
A checksum error does not tell you which character represents the intended policy. It can be caused by formatting damage or by an actual change to keys or paths. Replacing the suffix to match the damaged expression only makes the damaged expression internally consistent.
Return to an independent copy where possible. Avoid manually editing real keys or changing derivation paths until an address happens to show a balance. That can produce misleading results and makes the recovery process harder to reproduce.
Use local inspection with realistic limits
Bitcoin Core documents getdescriptorinfo as a way to analyze descriptors and obtain a canonical representation with a checksum. Check the installed version's help for its exact response fields. Work with a public example or an appropriately protected local setup. Neither a checksum utility nor this explorer needs a private descriptor sent to a third-party server.
Formatting also matters. If a descriptor travels through a document editor, check for altered quotation marks, missing characters and inserted whitespace. Preserve an exact machine-readable copy alongside any human-readable recovery instructions.
Keep the checks in order
A practical inspection separates four questions: does the text parse; does its checksum agree; does it derive the expected scripts; and does the intended signing arrangement actually control those scripts? Only the last question concerns spending authority.
Checksums help protect the integrity of a descriptor backup. They do not establish who owns the wallet, whether its cosigners remain available or whether the chain scan has found every relevant transaction.
Sources and further reading
Key takeaways
- A descriptor checksum catches accidental corruption; it does not authenticate its author.
- Generating a new checksum cannot recover the intended content of a damaged descriptor.
- Compare derived addresses and preserve the complete policy, not just the suffix.
Common questions
Can an attacker make a valid descriptor checksum?
Yes. The checksum calculation is public. A deliberate replacement can carry its own valid checksum.
Does a checksum prove a wallet is recoverable?
No. Correct policy, key material, cosigner access, ranges and compatible recovery software still matter.