Bitcoin’s most painful failure mode is not volatility or exchange collapses. It is the quiet moment when a holder discovers that a seed phrase, the twelve or twenty-four words they were told to guard with their life, is simply not enough to bring a complex wallet back from the dead. A newly merged proposal in the Bitcoin Improvement Proposals repository, BIP138, takes direct aim at that gap, and its authors are unusually candid about the price users will pay for the fix.
The wallet-backup specification was merged into the BIPs repository on Sept. 21 and remains a draft, meaning it is a published design for wallet vendors to study and implement, not a change to Bitcoin’s consensus rules. But the problem it addresses is old, widespread and growing: multisignature wallets that become permanently unrecoverable even though every surviving signer still holds a valid seed.
Why a seed phrase alone cannot save a multisig
A multisignature wallet requires more than one signer to spend. Its descriptor, a small piece of structured data, records the public keys and spending rules that tell wallet software how to reconstruct the account and locate its coins on the blockchain. A seed phrase can regenerate one signer’s private keys, but if the descriptor is lost, the wallet can be impossible to rebuild from that seed alone. For wallets built on miniscript or other conditional spending paths, the script logic itself lives outside the seed, and without it the coins may as well not exist.
The proposal also documents a second, subtler failure. A wallet engineered to survive the loss of one seed can still lose that signer’s public key. When that happens, the remaining signers lack a piece of the script needed to recover the funds, even though the quorum threshold is technically intact. The authors are careful to scope the problem honestly: these are risks for wallets whose spending setup depends on information beyond a seed, not a claim that every Bitcoin wallet needs this backup format.
An encrypted envelope for the parts a seed cannot restore
BIP138’s answer is an encrypted backup file that holds descriptors, wallet policies and other non-seed metadata. Private key material must be stripped before the file is encrypted, so the backup never becomes a second copy of the secret itself. Instead, a holder of an eligible extended public key, or xpub, from the backed-up wallet can decrypt a copy without the wallet’s seed, revealing the public keys and script structure needed for recovery while never gaining the private keys required to sign a transaction.
The draft deliberately narrows who counts as eligible. Public keys that appear directly in a script, and xpub roots that could be exposed by the act of spending, are excluded as recovery keys. If a cosigner’s key falls outside the eligible set, that cosigner cannot use it to open the file. Those limits are designed to keep an on-chain public key from doubling as a key to the off-chain backup.
The hidden cost
The tradeoff sits at the center of the proposal’s privacy warning. The exposure is conditional rather than an observed breach, but the scenario is realistic: if a wallet-service server already knows an account xpub, and that same xpub is reused as an eligible multisig key, the server could decrypt the backup if it ever obtains a copy of the file. It would then learn the wallet metadata inside, including the structure of otherwise private arrangements. That disclosure would not hand the server spending authority, but metadata leakage in Bitcoin is rarely harmless; script structure can reveal spending policies, heir configurations and the timing logic behind inherited or escrowed funds.
For users, the practical guidance is to treat the backup file like the sensitive document it is, store it separately from key material, and avoid reusing xpubs across services that were disclosed before the multisig wallet was created. The proposal’s design assumes disciplined key hygiene that many real-world users have never practiced.
Implementation status and what happens next
Development is further along than is typical for a freshly merged draft. A public Rust implementation with command-line build instructions already exists, and the BIP text acknowledges that Liana, a Bitcoin wallet focused on recovery and inheritance use cases, uses an earlier backup format that is incompatible with the current BIP138 file. That admission signals both momentum and friction: the wallet ecosystem most likely to adopt the standard is also the one that must migrate to it.
The merge therefore establishes a published draft, not a network upgrade and not a guarantee that today’s wallets can create or restore this format. Adoption will be decided vendor by vendor, and the real test will come the first time a recovery succeeds, or fails, on production funds. For a protocol that has promised self-custody as its core value proposition, solving the multisig recovery gap is less a luxury than an overdue debt, and BIP138 is the most concrete attempt yet to pay it without pretending the privacy cost does not exist.
Market context at the time of writing: Bitcoin traded near 84,536 USD, Ethereum near 2,690 USD and Solana near 122 USD, little changed on the day as developers quietly worked on the plumbing beneath the prices.
BIP138 finally admitting what multisig users learned the hard way. a seed phrase without the descriptor is just 24 words of nothing
@coldcard lost a 2of3 because one signer died and nobody could find the xpub. wouldve paid good money for this years ago ngl
@sigfile_sam the xpub hunt after a signer dies is pure nightmare fuel. weeks of dead ends over a string that was public information the whole time
had a 2-of-3 setup go stale years ago when one wallet vendor died and nobody could reconstruct the descriptor. whatever fixes that is worth the privacy hit imo
this is exactly the gap. a seed phrase alone cant recover a multisig, you need the descriptor too and most people never exported it
lol every hardware wallet tutorial skips this step. backed up my seeds twice, descriptor zero times
same here, two seed backups in two locations and the descriptor exists only in my head. BIP138 acknowledging the privacy leak upfront is refreshing, most standards pretend tradeoffs are for other people
same, two seed cards and nothing else in the ledger pouch. the BIP138 backup goes on paper the day a vendor actually ships it
The privacy tradeoff section is the honest part most proposals skip. Metadata leaking on every backup is a real cost, glad the authors said it out loud.
the fact that losing one public key can brick a wallet even when the quorum survives is such a quiet design failure. good on them for documenting it
a draft BIP admitting the backup leaks wallet structure is rare candor. shame it still needs ledger and trezor to move on firmware, history says that takes years
Credit to the authors for admitting the backup leaks privacy data. Most BIPs pretend tradeoffs dont exist.
honest about the leak and still worth it imo. my descriptor lives on a steel plate next to the seeds now, learned that lesson before any BIP existed
still just a draft tho. wallets taking years to implement backup standards is the actual bottleneck, not the BIP itself
counterpoint: a draft that wallets actually want to implement ships faster than a perfect one they ignore. the descriptor backup part is small enough that Sparrow et al could add it this cycle
sparrow adding descriptor export is table stakes at this point. the real lag is hardware wallet firmware, ledger and trezor take years to move on backup ux
ledger and trezor moving on backup firmware, thats my cue to stop holding my breath. been waiting since the descriptor wallet migration for the same thing
And history says third party wallets ship it first anyway. Sparrow had descriptor export before either hardware vendor even mentioned backups.
@rune_bek fair, but the privacy leak is what makes vendors hesitate in the first place. a draft nobody ships helps nobody either
the merged-on-sept-21 part matters less than everyone thinks. vendors will drag this out for years like descriptor wallets themselves, remember how long that took
took what, five years for descriptor wallets to become default everywhere. BIP138 is a draft plus vendor goodwill, so yeah, half a decade minimum
bricked wallet with surviving quorum happened to a friend and watching him beg a dead vendor support inbox for an xpub converted me on this instantly. ship it
same conversion story here. chased an xpub through a dead vendors support inbox for a month, bought a steel descriptor plate the week after
a draft that openly says the backup leaks wallet structure is rare candor for a BIP. vendors will still implement it three different ways
three incompatible vendor implementations of a backup standard is how you end up needing a BIP to fix the BIP. test vectors or bust