Technical guide · 14 min read

Multisig Wallet Recovery

A deep dive into recovering 2-of-3 and 3-of-5 Bitcoin multisig wallets — Unchained, Casa, Sparrow, Electrum — when one or more cosigner keys go missing. The good news: losing one key in a sensibly designed multisig is a drill, not a disaster. The bad news: losing M keys is permanent.

Bitcoin multisig is the gold standard for protecting larger amounts. Instead of a single private key that can be stolen, lost, or coerced, funds are locked to a script requiring M of N signatures. A 2-of-3 setup tolerates the loss of any one key. A 3-of-5 tolerates two. Multisig eliminates single points of failure — but it also introduces a new failure mode: losing enough keys that the threshold can never again be met. This guide walks through what is recoverable, what is not, and exactly how to rebuild a multisig wallet from the artifacts you still have.

The multisig rule of thumb: Losing up to N − M keys is survivable. Losing more than that is terminal. A 2-of-3 tolerates 1 loss. A 3-of-5 tolerates 2. Count carefully before panicking — or before relaxing.

The anatomy of a multisig wallet

A Bitcoin multisig address is not a single key — it is a script. Specifically, it is a P2SH, P2SH-P2WSH, or P2WSH address whose locking script is an OP_CHECKMULTISIG (or, post-Taproot, a MuSig2 aggregate). The script encodes: the threshold M, the total N, and N public keys in a defined order. To recreate the address you need every one of those N public keys, in the correct order. To spend from the address you additionally need any M of the corresponding private keys.

This is why multisig recovery has two distinct parts: reconstructing the watch-only wallet (which needs public data only) and providing the signing keys (which need M private keys / hardware devices / seed phrases). They fail for different reasons. You can have the ability to see a balance but not spend it. You can have signing keys but no idea what address they secure. Recovery often means assembling both halves from whatever survives.

What you need to rebuild a multisig

In order of importance:

  • The output descriptor — a single string that encodes script type, derivation paths, key origin fingerprints, and all xpubs in the right order. If you saved this (Sparrow exports it on setup; Unchained provides a PDF), rebuild is trivial.
  • All N xpubs — the extended public keys for every cosigner. xpubs are safe to share, and each hardware wallet exports them. If you have all xpubs but no descriptor, you need to know the script type (usually wsh / sortedmulti) and derivation path (usually m/48'/0'/0'/2' for native segwit).
  • M of N signing devices or seeds — the actual private keys, usually on hardware wallets. For 2-of-3, two devices suffice. These sign transactions; they don't reveal keys.
  • The original policy details — if you're unlucky enough to have no descriptor, you need to remember: (a) exact threshold M, (b) script type (P2WSH vs P2SH-P2WSH vs P2SH), (c) whether the multisig uses sorted or unsorted key order, (d) derivation paths. Sparrow and most modern wallets use sorted keys (BIP67).

Output descriptors — the universal backup

Since BIP380 / BIP381, Bitcoin wallets standardized the output descriptor. A 2-of-3 native segwit multisig looks like:

wsh(sortedmulti(
  2,
  [abcd1234/48'/0'/0'/2']xpub6E...cosigner1.../0/*,
  [ef567890/48'/0'/0'/2']xpub6E...cosigner2.../0/*,
  [12ab34cd/48'/0'/0'/2']xpub6E...cosigner3.../0/*
))#checksum

Break that down:

  • wsh(...) — native SegWit (bc1q... addresses). Use sh(wsh(...)) for wrapped segwit or sh(...) for legacy.
  • sortedmulti(2, ...) — BIP67 sorts keys lexicographically. If your wallet used unsorted, it would be multi(2, ...).
  • [abcd1234/48'/0'/0'/2'] — the 8-hex-char fingerprint of the master key plus the derivation path. This lets wallets find the right key on a hardware device.
  • xpub6E.../0/* — the extended public key, then a subpath where 0 is the receive branch and * is every child.
  • #checksum — an 8-character BCH-style checksum that lets wallets detect one-character typos.

If you exported this string at wallet creation, save it in three separate places: printed on paper in your safe, in your password manager, with your attorney or inheritance plan. The descriptor contains zero sensitive information (xpubs cannot spend) but is the single most important piece of data for rebuilding the wallet.

Scenario 1: Descriptor saved, lost one hardware wallet

This is the cleanest recovery. You drop into Sparrow Wallet → File → New Wallet → paste the descriptor. Sparrow parses it, shows your balance and history immediately (watch-only). When you want to spend, you connect the two remaining hardware wallets and produce a Partially Signed Bitcoin Transaction (PSBT). Sparrow builds the transaction, you route it through each surviving signer, broadcast. The lost third key is never touched.

Optional: once funds are safe, create a brand-new 2-of-3 with a replacement hardware device, send everything to the new address, and destroy the old one. The original public script is now effectively frozen — no one (not even you, not your kids) can ever reconstruct the M-of-N again with only two keys, but also no one with only one of the missing-key fragments can interfere.

Scenario 2: No descriptor, all three xpubs found, one seed lost

Search every device, every password manager, every PDF from the wallet vendor. Vendors like Unchained and Casa mail you a PDF at setup that lists each xpub explicitly. Sparrow writes a *.json file with the wallet config, which contains all xpubs and the script type. Electrum stores them in the wallet file.

With all N xpubs collected, you need to guess three things to construct a descriptor: (a) script type — try wsh first, fall back to sh(wsh(...)), sh(...); (b) sorted or unsorted — try sortedmulti first since it's the modern default; (c) derivation pathm/48'/0'/0'/2' for BIP48 native segwit multisig, m/48'/0'/0'/1' for wrapped segwit, or m/45' for older Electrum. Plug each combo into Sparrow until the first receive address matches a historical transaction in the blockchain.

# Via bitcoin-cli: derive address from candidate descriptor
bitcoin-cli deriveaddresses \
  "wsh(sortedmulti(2,\
    [abcd1234/48h/0h/0h/2h]xpub6E.../0/*,\
    [ef567890/48h/0h/0h/2h]xpub6E.../0/*,\
    [12ab34cd/48h/0h/0h/2h]xpub6E.../0/*))#csum" \
  "[0,0]"
# Output: ["bc1qexample...addr0"]
# Compare to block explorer for a known-historical receive address.

Scenario 3: Missing one xpub entirely

If one xpub is gone but you still have that cosigner's hardware wallet, just re-export the xpub — it's deterministic from the seed. On a Coldcard: Advanced → MicroSD → Export XPUB. On a Trezor: via Sparrow's "Connect" → the xpub is read from the device. The xpub depends only on the seed + derivation path, so it is always recoverable from the device itself.

If an xpub is gone AND the corresponding seed is also gone, and you have no record of the xpub anywhere, the multisig address set is cryptographically unreconstructable. Your remaining keys are useless. This is why Casa and Unchained emphasize saving the PDF — loss of one key is survivable, loss of one xpub fingerprint is not.

Scenario 4: Unchained collaborative custody, forgot password

Unchained Capital holds key 3 and provides a 2-of-3 where you hold keys 1 and 2. Your account password protects your dashboard but does not itself lock the bitcoin. If you forget the dashboard password: use account recovery (ID verification, security questions, support tickets). If you lose one of your hardware wallets: use Unchained's co-signing plus your other hardware wallet (classic 2-of-3). If you lose both of your hardware wallets: Unchained's "inheritance" or "concierge recovery" process uses notarized identity verification to grant access to their key plus help you add a new one — this is contractual, not cryptographic. Casa works similarly.

Scenario 5: You have the wallet file but the passphrase is lost

Some wallets (Electrum especially) let you put an encryption password on top of the multisig file itself. The underlying multisig script is in the file, but the private keys (or watch-only data) are AES-encrypted. If you forget that password but still have the file, GPU recovery is possible — Electrum uses PBKDF2 + AES-256 and is covered by btcrecover and hashcat. See our Electrum wallet password recovery guide for full attack procedure. This is completely separate from the multisig threshold itself — you're just unlocking the file.

Sparrow step-by-step rebuild

  1. Launch Sparrow Wallet (free, open-source, runs your own node or Sparrow's public Electrum server).
  2. File → New Wallet. Give it a name.
  3. Policy Type: Multi Signature. Script Type: Native Segwit (P2WSH) unless your originals used something else.
  4. Set the threshold: for a 2-of-3, put "Cosigners: 3" and "Threshold: 2".
  5. For each of the three keyslots, click "Connect Hardware Wallet" (if you still have the device) or "Enter xpub manually" (for lost or archived keys).
  6. After all three are imported, Sparrow shows the first receive address. Compare against the blockchain — visit a block explorer, look up a historical address, verify match. If mismatch: likely sorted vs unsorted, or wrong script type, or wrong path.
  7. Once matched, click Apply. Sparrow syncs the full transaction history. You can export the descriptor (Wallet → Show Wallet Details) — save this immediately, you now have the master backup.
  8. To spend: Send tab → build transaction → Export PSBT → sign on each of the M surviving hardware wallets in turn → Import back → Broadcast.

Realistic recovery matrix

Fully recoverable

  • • Descriptor saved + M of N signers intact
  • • All xpubs findable + M of N seeds / devices
  • • Wallet file + password forgotten (GPU attack)
  • • Custodial wallet + ID verifiable (Unchained, Casa)
  • • 2-of-3 with 1 key lost, 2 present

Not recoverable

  • • 2-of-3 with 2 or 3 keys lost
  • • 3-of-5 with 3+ keys lost
  • • Missing xpub AND missing seed for same cosigner with no record
  • • Unknown script type + 10+ plausible paths exhausted

A concrete real-world example

A client held a 2-of-3 Sparrow multisig: Key A on a Coldcard Mk3 (home safe), Key B on a Trezor Model T (office desk drawer), Key C as a 24-word seed stored inside an encrypted Dropbox note. Their Dropbox got wiped after account password loss — Key C gone. Panic ensued. But the client had stored the descriptor on a printed PDF inside the home safe. We walked them through: Sparrow → New Wallet → paste descriptor → first receive address confirmed. Connected Coldcard and Trezor → built PSBT → signed with both → broadcast. Funds moved to a fresh 2-of-3 within two hours. The Dropbox/Key C disaster was fully neutralized because the descriptor survived and the threshold was still met.

Contrast with a 3-of-5 Casa setup where a client lost two seeds in a house fire, then lost a third device to a bricked firmware update. Three keys gone → only two remaining → threshold cannot be met. Casa's own key brought them to three, but that is still one short of the 3-of-5 required. The funds are permanently inaccessible. No service can brute force this — the cryptography is not the problem, the missing authorization signatures are.

Design lessons for future-you

  • Save the descriptor. Print it on paper. Three copies. Different geographic locations. This is non-negotiable.
  • Document each cosigner: which hardware wallet model, which seed location, who holds the recovery passphrase. A notebook in the safe beats any digital note.
  • Test recovery before you need it. Restore the descriptor to a fresh Sparrow install. Sign a test transaction. Confirm it broadcasts. Then delete the test wallet — you now know it works.
  • Prefer 2-of-3 over 2-of-2. A 2-of-2 has zero redundancy — any single loss is terminal. A 2-of-3 costs one extra device and one extra backup location and survives any one failure.
  • Prefer 3-of-5 over 2-of-3 for large estates. More redundancy, harder to coerce, better for inheritance planning across multiple heirs.
  • Don't reuse seeds across cosigners. Two cosigners sharing the same seed reduces your N to N − 1 effective independence.

Related guides

Frequently asked questions

Can I recover a 2-of-3 multisig if I lost one key?

Yes. 2-of-3 tolerates exactly one lost key. You need all three xpubs to rebuild the watch-only wallet and any two hardware wallets / seeds to sign a spending transaction.

What is the difference between xpub and xpriv?

xpub (extended public key) derives only receive addresses — safe to share. xpriv (extended private key) derives private keys and can spend funds — never share. Multisig rebuild needs all N xpubs and M of N xprivs.

What is an output descriptor?

A BIP380-standard string that encodes script type, derivation paths, every xpub in order, and a checksum. The universal multisig backup — save this and any wallet can rebuild yours.

What if I lost two keys in a 2-of-3?

Funds are unrecoverable by any means. The threshold of two signatures cannot be met with only one key. No brute force or service can bypass this — the cryptography is doing exactly what it was designed to do.

Does Unchained or Casa custody my keys?

They hold exactly one of the keys in a 2-of-3 or 3-of-5 collaborative custody. You hold the majority. Their key is only useful if your majority-threshold keys are still intact — they cannot spend unilaterally.

GPU recovery for encrypted multisig files

If your Sparrow, Electrum, or Bitcoin Core multisig wallet file is encrypted and you forgot the file password, our GPU farm can attempt recovery. Threshold cryptography still requires M of N keys, but file-level encryption is a separate solvable problem.