Imagine opening your Bitcoin recovery kit and discovering that you did almost everything right.
You built a 2-of-3 multisig wallet.
You separated the signing devices.
You backed up the seeds.
You accepted the extra complexity because you wanted to survive losing one key without trusting a company to return your money.
Years later, one signer is gone. Two seeds survive. That is exactly the failure your setup was supposed to handle.
Then you discover that the laptop containing the wallet configuration is gone, too. So is the only other copy of that file.
You can recreate your two signing keys. You cannot recreate the missing cosigner’s public-key information. You no longer have everything needed to reconstruct the original wallet scripts.
The Bitcoin is still on the blockchain. The network is still running. Your surviving seeds are correct.
Your recovery plan may nevertheless have failed.
This is the uncomfortable gap between owning enough keys to satisfy a spending rule and preserving enough information to reconstruct that rule.
Bitcoin culture has spent years teaching people to protect their seeds. It has been much less successful at explaining everything else that might need to survive alongside them.
That is what makes ** BIP138** interesting.
Everyone is obsessing over AI’s profitability. But the creators aren’t trying to build a business—they’re building a new reality where money itself becomes obsolete.
** Bitcoin Optech’s September 25, 2026 newsletter** highlighted its addition to the BIPs repository. The proposal describes a way to encrypt wallet recovery information using public-key material already associated with the wallet, allowing an eligible cosigner to recover that information without remembering another password.
The convenience is obvious. The privacy implications take a little longer to sink in.
The information that opens your backup may be information you already gave away.
Before going further, the status matters. ** BIP138** is a draft application-layer specification.
Think of it as a proposed common language for a neglected part of self-custody: keeping the wallet’s instructions recoverable without exposing them unnecessarily.
The proposal deserves attention because the problem will outlive whichever hardware wallet is fashionable this year.
Your seed phrase is an extraordinarily compact backup. A few words can reproduce a huge tree of keys. That makes it easy to assume those words reproduce the entire wallet.
For familiar single-signature setups, software can often fill in the missing context by checking common address types and derivation paths. The recovery experience feels almost magical, which encourages the idea that the seed contains everything.
More elaborate wallets make the missing context harder to ignore.
A multisig wallet needs to know which public keys belong together, how to derive their descendants, which script construction to use, and how many signatures are required. A wallet with timelocks or multiple recovery branches needs additional instructions describing those conditions.
A descriptor records that structure in a form software can interpret. The ** BIP380 descriptor specification** explains why keys alone leave ambiguity about which scripts and addresses a restored wallet should generate.
A useful analogy is a building with several authorized keyholders. The keys matter enormously. So does knowing which building they belong to, how its doors are arranged, and which combinations open them.
In a standard 2-of-3 wallet, two signatures may authorize a spend, while information about all three public keys is needed to reconstruct the relevant script. The threshold tells you how many signatures you need. It does not tell you how much configuration you can afford to forget.
Losing a descriptor is not automatically a death sentence. If every seed survives and the construction is known, reconstruction may be possible. Other surviving records, devices, cosigners, or previously revealed scripts can sometimes help.
But “perhaps we can reconstruct it” is a miserable substitute for a backup strategy.
The whole point of recovery planning is to avoid depending on luck, specialist detective work, and the availability of a person who remembers what you did twelve years ago.
Your backup should preserve the wallet you actually built, not the wallet your future software guesses you probably built.
This is where self-custody creates a difficult balancing act.
You want the wallet configuration to exist in enough places that a dead laptop, a house fire, or a disappearing service cannot erase it. Yet a public descriptor can expose the wallet’s structure and allow someone to derive its addresses and examine associated activity.
That does not give an observer your private keys. It can still give them a remarkably useful financial map.
In the ** original Delving Bitcoin discussion**, Ingala distinguished the secrecy needed for spending keys from the privacy needed for descriptors. That distinction explains why the two kinds of backup deserve different treatment.
A seed leak can compromise spending authority. A public descriptor leak can compromise visibility into the wallet. Both matter, but making more copies has different consequences for each.
Treating the descriptor exactly like a seed can make it unnecessarily difficult to preserve. Treating it like an ordinary shopping list can expose information you never intended to share.
Encryption offers a way to make redundant copies while limiting who can read them. The next problem is deciding what unlocks the encryption.
