A Bitcoin output descriptor ends with an eight-character checksum when its author includes one. During a wallet import, that suffix gives the software a way to catch mistakes in the copied text. Bitcoin Core exposes the checksum alongside other results, including whether the submitted descriptor contained private keys. Those fields do different jobs.
| What you need to know |
|---|
| A descriptor describes Bitcoin output scripts and can include keys and derivation paths. |
| Its optional suffix contains an eight-character alphanumeric checksum. |
| Bitcoin Core can calculate a checksum for descriptor text that has no suffix. |
| The getdescriptorinfo result reports private-key presence separately from the checksum. |
A valid checksum can accompany the wrong keys
Bitcoin Core’s descriptor reference describes the suffix as protection against typos and copy-and-paste errors. A descriptor can describe a single output or a collection of outputs, using expressions that specify script types, keys and, where relevant, derivation paths. The checksum belongs to that text.
The reference gives different detection guarantees for particular character substitutions, letter-case changes and descriptor lengths. That qualification matters: a successful check is not a claim that every possible alteration can be detected. Nor does an error-detection rule establish that the key inside the text is the key the wallet owner intended to use.
There is a simple reason a valid suffix cannot authenticate the sender. Bitcoin Core’s getdescriptorinfo command can calculate a checksum for a descriptor that has none. Someone can therefore supply different valid descriptor text together with a checksum calculated for that text. Both pieces may agree while the intended wallet identity remains unresolved. This is a consequence of the documented calculation facility, rather than a reported attack.
Why hasprivatekeys can remain true
The Bitcoin Core 30.0 RPC reference lists separate results for the canonical descriptor, checksum, whether the descriptor is ranged, whether it is solvable and whether the input contained any private keys. These are separate properties. The presence of a checksum does not answer the private-key question.
In particular, the documented canonical descriptor is returned without private keys, while hasprivatekeys describes the original input.
An output that shows a public-only canonical descriptor can therefore accompany a true private-key flag. Looking only at the displayed canonical text would miss that distinction. Do not treat that cleaned-up result as evidence that the text originally pasted into a tool contained no secret material.
Private keys can occur inside a descriptor: the reference permits both WIF keys and extended private keys where their public counterparts are supported. Keep the original private when checking a backup. The useful result of an import check is therefore a set of answers: the text passes its checksum, the keys match the intended wallet, and any private-key material stays out of shared diagnostics. Only the first answer comes from the eight-character suffix.
