Multisig Wallet Recovery and Descriptors

This article covers Bitcoin script-based multisig specifically — threshold signing implemented through Bitcoin Script and descriptors such as multi()/sortedmulti(). Other blockchains, smart-contract multisig wallets and MPC (multi-party computation) schemes use the same words — threshold, cosigner, policy — very differently, and are out of scope here. A Bitcoin multisig wallet does not fail like a single-key one — losing one cosigner’s seed does not necessarily mean losing the funds, and having enough keys does not necessarily mean the wallet is easy to rebuild.

Threshold first: how many of how many

A multisig wallet is defined by a threshold — a “2-of-3” or “3-of-5” setup, for example — and recoverability starts with that number, not with counting surviving seeds in isolation. Two working cosigners out of three is normally sufficient to spend; two out of a required three is not, no matter how confident the two remaining backups look. The threshold counts distinct, suitable signing keys for the matching script: two copies of the same seed, however they are stored, are one cosigner, not two, and don’t increase how many independent failures the wallet can tolerate. A key fingerprint alone is a short identifier, not proof of independence or of a full key match — confirming that a candidate key actually belongs to the policy needs the full public key or extended public key, not just its fingerprint.

Signing material vs. wallet policy

Enough private keys to meet the threshold can make funds spendable. Rediscovering the exact set of historical outputs those keys control efficiently is a separate question, and depends on the wallet’s construction — cosigner public keys or extended public keys, derivation paths, script type, and ordering rules such as sorted multisig. In practice, a coordinating wallet’s saved configuration can be as valuable for recovery as an individual cosigner’s seed.

Descriptors make construction explicit

Modern output descriptors describe this construction directly rather than leaving it implicit. wsh(sortedmulti(2, xpub_A/…, xpub_B/…, xpub_C/…)) describes a native P2WSH 2-of-3 multisig; the same policy wrapped as nested P2SH-P2WSH instead would be written sh(wsh(sortedmulti(2, xpub_A/…, xpub_B/…, xpub_C/…))) — per the Bitcoin Core descriptors specification, the wrapper determines which address type and script the wallet actually uses, not just the key count. The ellipses and xpub_A-style labels here are schematic placeholders standing in for real extended public keys and derivation paths; neither example is an importable descriptor, and a real one should never be built with placeholder key material or a fabricated checksum presented as valid. Where a real descriptor or an equivalent wallet-policy export survives, reconstruction is far more direct than reverse-engineering the setup from keys alone.

What to preserve: the policy artifacts

Beyond the signing keys themselves, reconstructing a multisig wallet needs its policy — the exact rules a coordinator used to turn keys into addresses:

• The threshold (k-of-n).
• The full set of cosigner public keys or extended public keys — not just fingerprints.
• The script wrapper: native P2WSH, nested P2SH-P2WSH, or another variant.
• Key origins and derivation paths for each cosigner.
• Which branches are receive vs. change.
• The network (mainnet, testnet, etc.).
• The address range already used, to re-derive the right history.
• The coordinator software's export format and version.

A public descriptor or an xpub-only export can let someone discover which addresses belong to the wallet without by itself giving them the ability to sign for it — spending still needs the actual private keys. The reverse also matters: an xpub does not substitute for a private key, and sharing one, even for recovery purposes, reveals the wallet's address history to whoever receives it. Extended key material recovered from a backup may itself be encrypted or otherwise inaccessible, so having a backup is not the same as having a signer that currently works; recovering it may be its own sub-problem — see Recovering Encrypted Wallet Files and Keystores.

Derivation conventions for multisig

BIP48 documents a common multisig derivation path (m/48'/coin_type'/account'/script_type'/change/index, with the script-type field distinguishing nested P2SH-P2WSH from native P2WSH) by standardizing existing industry practice. It is a common convention, not the only possible path a given coordinator may have used — wallet-specific derivation conventions also exist outside it, which is another reason to preserve the exact coordinating software and version alongside the keys themselves.

PSBT moves signing data, not keys

A Partially Signed Bitcoin Transaction (PSBT, defined in BIP174) is a format that lets separate signers — potentially on different, offline or air-gapped devices — pass a transaction back and forth and each add their own signature. It is a transport and coordination mechanism, not a substitute for a lost key or seed: a PSBT only lets a signer who already controls a valid private key contribute their part of the signature.

One lost cosigner seed is not automatically a lost wallet

Because spending only requires meeting the threshold, a single missing or destroyed cosigner backup in an N-of-M setup with at least N surviving, working signers does not by itself prevent spending — it's the threshold that matters, not a strict majority of all original signers. That isn't the same as saying nothing changed: the margin for a second loss is thinner, and a compromised signer is a different risk from a lost one — losing a backup reduces resilience, while a signer's key being exposed to someone else is a confidentiality problem the remaining honest signers can't undo by themselves. Either way, it is worth restoring the missing signer’s capacity rather than continuing to operate below the original design threshold.

Three recovery scenarios

Scroll horizontally to see the full table →

Preserve the coordinator’s configuration, not just keys

Wallet-coordinator software — the application that tracks the multisig setup and assembles signatures — often stores exactly the policy information described above. Back up its configuration file or descriptor export alongside the individual signer backups: losing it can turn an otherwise-recoverable wallet into an expensive reconstruction problem even with sufficient keys in hand.

Verify reconstructed outputs against known addresses

Before relying on a rebuilt multisig configuration, confirm it derives addresses and unspent outputs that match what was actually observed on-chain — the same principle as single-key verification, but with more configuration variables that could each be subtly wrong. This kind of verification is read-only: it checks derived addresses and transaction history against what is already publicly observable, and should happen before any spending is attempted. Broadcasting a transaction or moving funds is outside what this article covers.

Technical references: Bitcoin Core: output descriptors — multi() and sortedmulti() · BIP48 — multisig derivation paths · BIP174 — PSBT format

Related: Wallet Seeds, Derivation Paths and Account Reconstruction · Cryptocurrency Wallet Recovery Workflow · Recovering Encrypted Wallet Files and Keystores · Recovery Copies