I classified 551 wallet-recovery questions: almost nobody lost their seed

Everything written about backups assumes the danger is losing the twelve words. I went to look at what people who actually had the problem were asking.

What those 429 are missing

Not the seed. The record of how the wallet is rebuilt from it: script type, derivation path, network, and whether there was a passphrase.

In Bitcoin Core that record has a name and a syntax: the output descriptor, documented in doc/descriptors.md. Almost nobody writes it down, because nobody is ever handed it. The seed comes with a ceremony — write these twelve words, now confirm three. The descriptor comes with none.

Why the gap never announces itself

This is the part that turns a missing field into an afternoon of panic. The same public key can be written in more than one script type, and each produces a different, perfectly valid address:

• pkh(KEY) — addresses starting with 1
• sh(wpkh(KEY)) — starting with 3
• wpkh(KEY) — starting with bc1q
• tr(KEY) — starting with bc1p

Four addresses that are all "yours" from the same key, and three of them can read zero. Nothing fails, nothing warns. You restore, you see zero, and the software behaves perfectly normally because it did exactly what you asked — at the wrong door.

The passphrase has the same property: under BIP-39 any string you type produces a valid wallet, and only the right one opens yours. There is no error message because there is nothing to compare against.

The test these numbers imply

If the problem is not losing the words but being unable to rebuild, then the right question is not "can I write my twelve words again?".

That question can be answered without risking anything, because an extended public key cannot sign. A node confirms it on its own: getdescriptorinfo answers hasprivatekeys: false, and deriveaddresses prints exactly the addresses that descriptor will produce.

And unlike the seed ritual — confirming three words proves you copied them, not that the backup works — this test is checkable: you type from your own paper, address zero is derived, and you match it against what your wallet shows. If they match, your backup rebuilds the wallet. If they don't, you now know what is missing, and you did not find out on the day it mattered.

The ceremony runs that check in under two minutes. It runs in your browser, never asks for the seed, and the page declares connect-src 'none' — it cannot send anything anywhere, and that is in the headers, verifiable.

The limits of this

Counting questions measures what people asked, not what happened to them. Someone who lost the seed outright probably never posts — they already know there is nothing to be done, and that absence never enters the count. So these numbers do not say "losing your seed is rare". They say that among the problems that still have a fix, almost none are the seed.

Which is exactly the set where intervening is worth anything.