Bitcoin developers merge draft proposal to recover multisig wallets at privacy expense

• BIP138 was merged into the Bitcoin Improvement Proposals repository on Sept. 21, but remains marked Draft.
• The encrypted backup stores descriptors and wallet policies while private key material is stripped before encryption.
• A holder of an eligible extended public key can decrypt a backup copy without ever touching the wallet’s seed phrase.

• Sep 21 date BIP138 merged as Draft, six days before this report
• 255 cap on decoy secrets padded into each backup file
• 0x00 byte now read as padding start, not payload rejection

A new Bitcoin backup format built to rescue multisignature wallets from configuration loss reached draft status this month, merging into the Bitcoin Improvement Proposals repository on Sept. 21. The proposal, first reported by CryptoSlate, targets a specific failure: a seed phrase can regenerate one signer’s private keys, but it cannot reconstruct the descriptor, the record of public keys and spending rules that tells wallet software how to find and spend a multisig account’s coins.

Losing that descriptor, or losing a cosigner’s public key in a wallet built to survive one lost seed, can leave otherwise-solvent coins unreachable. BIP138’s answer is an encrypted file holding descriptors and metadata that a holder of the right xpub can open without the wallet’s seed.

PR 1951 Merges BIP138 Into Bitcoin’s Proposal Repository as Draft

The BIP138 file removes private key material before encryption, so the backup itself cannot be used to sign transactions even if it is decrypted. What it does expose is the wallet’s script structure and public keys, the exact information needed to rebuild a multisig account when a descriptor or a cosigner’s public key has been lost.

That is a gap seed phrases alone have never covered, since a mnemonic regenerates keys for one signer but says nothing about how many signers a script requires or how they combine.

Merge into the BIPs repository puts the specification on Bitcoin’s standard review track alongside proposals like the post-quantum cryptography upgrade recently proposed for Lightning’s offchain layers, but Draft status means no consensus has formed and no wallet is obligated to implement it. A public Rust implementation with command-line build instructions already exists, giving wallet developers a working reference ahead of any formal adoption.

Excluded Keys Wall Off the Backup From Onchain Exposure

The draft’s core safeguard limits who can decrypt a given backup. Public keys that appear directly in a script, and xpub roots that spending would expose onchain, are excluded as recovery keys, so a cosigner whose key is excluded cannot open the file even if they later see it published in a transaction.

That design keeps a key visible on the blockchain from becoming a key to an offchain backup, addressing a gap no earlier standard covered in the same way.

The scenario the authors flag is narrower: if a wallet-service server already knew an account’s xpub before the multisig wallet was created, and that same xpub is later reused as an eligible recovery key, the server could decrypt the backup if it ever obtained a copy.

The BIP describes this as conditional exposure, not a reported breach, but it is the kind of custody detail institutions building on third-party coordination servers need to audit before reusing an xpub across wallet generations.

Reviewers also debated hiding how many people can open a given backup. A separate reviewer comment questioned whether nonces should be generated deterministically from the plaintext and keys to save 32 bytes, a proposal the authors have not resolved in the merged draft, leaving cryptographic minimalism unsettled against standard practice.

Liana Wallet Still Can’t Read the New Format

The BIP text itself notes that Liana, an existing Bitcoin wallet, already uses an earlier backup format incompatible with the current BIP138 file. During review, a contributor working on Liana’s own JSON-based backup said they planned to submit a separate BIP proposal rather than converge immediately on this specification.

The merge of BIP138 establishes a published draft, not a network change, and not a guarantee that today’s wallets can create or restore this exact file format.

The CCS read. For institutional custodians running multisig cold storage, the practical takeaway is that seed-only backup procedures already understate their own risk, independent of whether BIP138 itself is ever finalized. Any custody policy assuming a seed phrase alone restores a multisig vault should be reviewed now, and any xpub shared with a coordination server should be treated as a durable liability rather than a one-time disclosure.

BIP138 remains listed as Draft, with review comments still open on nonce generation and no committed timeline for wallets beyond the existing Rust reference to implement it. Whether Liana adopts the format, submits a competing BIP, or the ecosystem converges on KeysSoze’s broader payload proposal is the open question the merged pull request leaves unresolved.