Bitcoin’s BIP138 draft adds privacy risk to multisig wallet recovery
A newly merged Bitcoin proposal aims to fix a real recovery gap in complex wallets, but its own design creates a new party that could read sensitive wallet data without ever holding a private key. BIP138 addresses cases where a seed phrase alone cannot rebuild a multisignature or miniscript wallet, at the cost of a conditional privacy exposure the draft itself acknowledges.
- BIP138 was merged into the Bitcoin Improvement Proposals repository on September 21 but remains in Draft status.
- The specification stores encrypted descriptors and wallet policies that a seed phrase cannot regenerate for multisig setups.
- A holder of an eligible extended public key (xpub) can decrypt a backup copy without needing the wallet’s seed.
- Sep 21 date BIP138 merged into the Bitcoin BIPs repository as a draft
- #1951 GitHub pull request number that merged the proposal into the repository
Bitcoin’s BIP138 wallet-backup proposal was merged as a draft pull request into the Bitcoin Improvement Proposals repository on September 21. The proposal targets a specific failure mode in multisignature and miniscript wallets, where a seed phrase can regenerate one signer’s private keys but cannot reconstruct the descriptor that tells wallet software how to find and spend the coins. Losing that descriptor, or losing a cosigner’s public key when one seed is deliberately dropped for redundancy, can leave funds unrecoverable even with a working seed.
Merge sets a draft, not a network change
The BIP138 draft answers the descriptor problem with an encrypted file that holds descriptors, wallet policies, or other non-seed metadata needed to rebuild a multisig account. Private key material is stripped out before the file is encrypted, so the backup itself cannot expose spending keys. The story was first reported by CryptoSlate.
The full specification is published in the BIP-0138 document now sitting in the BIPs repository. Its merge establishes a formally reviewed draft that developers can build against, but it is not a change to the Bitcoin network’s consensus rules, and it does not guarantee that today’s wallets can already produce or restore files in this format.
An xpub holder can open the backup without a seed
The tradeoff sits in who can decrypt the file. Anyone holding an eligible xpub from the backed-up wallet can open a copy of the encrypted backup without possessing the wallet’s seed, revealing the public keys and script structure needed for recovery. That same access does not grant the ability to sign transactions, since the xpub alone contains no private key material.
The draft narrows who qualifies as a valid recovery key. Public keys that appear directly in a spending script, and xpub roots that a spending transaction could expose on-chain, are excluded, so a cosigner’s key cannot double as a key to the off-chain backup file.
The privacy concern arises when an xpub was disclosed before the multisig wallet existed, such as to a wallet-service provider. If that same xpub is later reused as an eligible multisig key, the provider could decrypt a backup copy if it obtained one, learning wallet metadata without gaining spending authority. BIP138 describes this as a conditional exposure tied to xpub reuse, not a reported breach of any deployed wallet.
A working Rust build exists but Liana stays incompatible
A public Rust implementation with command-line build instructions already accompanies the draft. The BIP notes that Liana, an existing Bitcoin wallet, uses an earlier backup format incompatible with the current BIP138 file, meaning adoption will require wallet developers to build support for the new specification rather than assume existing tools already comply.
The BlockWest read. Wallet builders and custodians running multisig setups for treasuries or client funds now face a design choice rather than a fix they can bolt on. Adopting BIP138 means auditing every place an xpub has ever been shared, since reused keys given to exchanges, cosigners or service providers could later unlock metadata those parties were never meant to see.
BIP138 remains in Draft status, so its excluded-key rules and encryption scheme can still change before wallets ship support for it. The open question for developers is whether Liana and other multisig wallets migrate to the new format, or whether the incompatibility the BIP flags persists as adoption spreads.
BlockWest is a news publication. Nothing here is investment advice. Read our disclaimer and editorial policy.
