Your Bitcoin backup is probably missing something: the descriptor

A restore drill that saw 15 of 21 BTC (regtest), and what to store.

Türkçe

Short version. If your Bitcoin setup uses multisig, Taproot script paths or a Miniscript inheritance policy, your recovery phrase alone is not a complete backup. You also need the output descriptor, with its checksum. And if you ever change the policy, the new descriptor is a different wallet address, so it must be backed up too.

A restore drill that found only 15 of 21 BTC (regtest)

On a Bitcoin Core 31.1 regtest network (no real money) I funded one wallet across three different descriptors: 15 BTC under the original policy and 3 BTC under each of two variants. The original wallet showed 21.0 BTC. Then I restored a brand-new empty wallet from only the original descriptor (rescan from the beginning). It saw 15.0 BTC in 3 UTXOs. The other 6 BTC sat at addresses that only the two other descriptors could derive, so the restored wallet could not see them.

A blank wallet with no descriptor at all saw 0.

Why this happens

The checksum matters, and it is checked

Descriptors end with an 8-character checksum (BIP-380). On Bitcoin Core 31.1, importing a descriptor with a wrong checksum is rejected with: Provided checksum 'aaaaaaaa' does not match computed checksum '…'. That is exactly the protection you want against a typo in a handwritten backup. Not every library enforces it, so verify with the software you will actually use.

What to store

Limits

Regtest with fake coins, one node, Bitcoin Core 31.1. Not investment, legal or tax advice.

Audit your own policy →