What is a Bitcoin multisig wallet?

A multisig wallet locks coins to a script requiring M signatures from N possible keys. BIP-11 defined the format as m, then the public keys, then n, then OP_CHECKMULTISIG. Bitcoin Core's consensus limit is 20 public keys per OP_CHECKMULTISIG. Bare multisig is only standard for n of 3 or fewer, so real wallets wrap the script in P2SH or P2WSH, which is why multisig addresses start with 3 or bc1q.

Which multisig quorum should I use?

2-of-3 for almost everyone. It is the only common quorum that survives both a lost key and a stolen key, because any two of the three sign and no single key does anything alone. 2-of-2 fails permanently if either key is lost. 3-of-5 tolerates two failures instead of one, but you now administer five devices and five backups, and the extra work is where mistakes come from.

What is a wallet descriptor and why does it matter for multisig?

A descriptor is the text record of which public keys form the wallet and how many must sign, for example wsh(sortedmulti(2,KEY1,KEY2,KEY3)) with an eight character checksum. Without it, software cannot reconstruct the addresses your coins sit in, so every key you kept is useless. Bitcoin Core's descriptor checksum detects up to four character substitutions in a descriptor up to 501 characters long.

How do you sign a multisig transaction across separate devices?

With a partially signed Bitcoin transaction, defined in BIP-174. The file passes through six roles: Creator builds the unsigned transaction, Updater attaches the previous outputs and key paths, each Signer adds a signature independently, Combiner merges the copies, Input Finalizer assembles the witness once the quorum is met, and Transaction Extractor emits the broadcastable transaction. It contains no secrets before signing, so it can travel by microSD card or QR code.

Why are multisig public keys sorted?

Because key order changes the script, and a different script means a different address. BIP-67 notes that an unsorted set could produce as many as 2(n!) valid redeem scripts, each with its own P2SH address, so two wallets given the same keys could disagree about where the coins live. Sorting compressed keys lexicographically makes the result deterministic. BIP-67 also warns this cannot be enforced as a network rule, because a P2SH address reveals nothing about the script inside it.

Is multisig worth the added complexity?

Only above the amount where a single seed phrase keeps you awake. Multisig removes the single point of theft and the single point of loss, but it adds a new single point of failure in the descriptor, more devices to keep firmware current on, and a recovery procedure that heirs almost certainly cannot run. Below that threshold, one hardware wallet with a tested steel backup fails in fewer ways.

What is the maximum number of keys in a Bitcoin multisig?

Twenty, set by Bitcoin Core's MAX_PUBKEYS_PER_MULTISIG constant. P2SH cannot reach it: the redeem script is capped at 520 bytes by MAX_SCRIPT_ELEMENT_SIZE, and 15 compressed keys at 34 bytes each plus three opcodes comes to 513 bytes, so 15-of-15 is the practical P2SH ceiling. P2WSH allows a standard witness script of 3,600 bytes, which fits all 20 keys comfortably.

GuideSecurity & Self-Custody

Bitcoin Multisig Wallet Setup: A Practical Guide

Published July 29, 2026~12 min read

A multisig wallet locks your coins so that M signatures out of N possible keys are needed to move them. Pick 2-of-3 and any two of your three keys spend the balance, while any one key alone is worthless to a thief and harmless to lose. That single change removes the two problems a seed phrase can never solve at the same time: it must be impossible for anyone else to find, and impossible for you to lose.

It also introduces a new way to lose everything, and this one is quieter. Your three keys are not the wallet. The descriptor is, and people who back up three seed phrases with great care routinely never back up the one file that makes those seeds mean anything.

Three cards comparing multisig quorums. A 2-of-2 wallet holds two keys, needs both signatures, survives losing no keys and survives theft of one key. A 2-of-3 wallet holds three keys, needs any two signatures, and survives losing any one key or theft of any one key. A 3-of-5 wallet holds five keys, needs any three, and survives losing or theft of any two. A band below states all three fail without the wallet descriptor. — Read the two middle rows together. A quorum is not chosen for security in the abstract, it is chosen for how many simultaneous disasters you want to shrug off.Original diagram by BTCLinks.

What is a multisig wallet underneath the interface?

It is a script, and it is older than most people assume. Gavin Andresen's BIP-11 was assigned in October 2011 and defined the standard form directly: m {pubkey}...{pubkey} n OP_CHECKMULTISIG. Signatures are supplied with a leading OP_0, which exists purely to feed a long-standing off-by-one bug in OP_CHECKMULTISIG that pops one stack item too many. Fifteen years later that OP_0 is still there, because consensus bugs get documented rather than fixed.

BIP-11 only made this standard for n of three or fewer, and that limit is why you never see bare multisig in the wild. Real wallets hash the script and put the hash in the output instead, which is what P2SH and P2WSH do. The coins land at an address starting with 3 or bc1q, and the network learns nothing about the arrangement inside until you spend. Our guide to Bitcoin address types covers why that distinction shows up in your fee bill later.

The ceiling is worth knowing because vendors are vague about it. Bitcoin Core's consensus constant MAX_PUBKEYS_PER_MULTISIG is 20. P2SH cannot get near that, because a redeem script is bounded by MAX_SCRIPT_ELEMENT_SIZE at 520 bytes: fifteen compressed keys at 34 bytes each is 510, plus three opcodes is 513, and a sixteenth key overflows. So 15-of-15 is the real P2SH ceiling. P2WSH raises the standard witness script limit to 3,600 bytes, which fits all twenty keys with room to spare.

Which quorum should you actually pick?

2-of-3, unless you have a specific reason not to. The other options are not wrong, they are just answers to questions most people are not asking.

Multisig quorums compared by resilience, administration burden and suitability
Quorum	Survives losing	Survives theft of	Devices to maintain	Honest verdict
2-of-2	nothing	1 key	2	A shared account, not a savings plan. One dead device is a permanent loss.
2-of-3	any 1 key	any 1 key	3	The default. The cheapest quorum that tolerates one of each disaster.
3-of-5	any 2 keys	any 2 keys	5	Real gain in resilience, real gain in the work you must keep doing.
2-of-4	any 2 keys	1 key	4	Loss-tolerant and theft-weak. Usually the wrong trade.
5-of-7	any 2 keys	any 4 keys	7	Institutional. If you are reading this to decide, it is not your answer.

The two failure columns are independent, and that is the whole design space. Raising the threshold buys theft resistance, raising the total buys loss resistance, and every extra device costs attention you have to keep paying.Table by BTCLinks.

One warning on 2-of-4 and its relatives. People pick them reasoning that four keys are safer than three, but a 2-of-4 still falls to any two stolen keys while giving an attacker a wider surface to steal from. Adding keys without raising the threshold makes theft easier, not harder.

What do you need before you start?

Three things, and the third is the one people arrive without.

N signing devices, from more than one manufacturer. Mixing vendors means a firmware bug or a supply-chain compromise at one company cannot reach your quorum. Buy each of them direct from the maker: Coinkite, Trezor, Foundation Devices, BitBox. Never a marketplace listing, for the reasons in our hardware wallet comparison.
A coordinator. Some software has to hold the descriptor, watch the addresses and assemble transactions. Sparrow, Nunchuk, Electrum and Bitcoin Core itself all do this. The coordinator never touches a private key, so picking one is a reversible decision, which is a nice change.
Somewhere to write down a long string of text. This is the descriptor. It is not secret, it is not optional, and it needs to exist in as many places as your seed backups do.

The part that actually loses coins

Here is the failure mode, stated plainly. You set up a 2-of-3. You stamp three seed phrases into steel, store them in three buildings, and feel finished. Two years later the laptop with the coordinator software dies. You now hold three perfectly good keys and you cannot construct a single one of your own addresses, because you never wrote down which extended public keys were in the wallet, in what quorum, on which derivation path.

The keys are not enough. A multisig address is the hash of a script, and to rebuild that script software needs every participant's public key, the threshold, and the derivation branch each key sits on. That bundle is the descriptor.

A 2-of-3 wallet descriptor shown as a string, then broken into five numbered parts: wsh which wraps the script into a witness script hash address, sortedmulti with threshold 2 which sets the quorum and sorts the keys, a bracketed key origin holding a master fingerprint and BIP-48 path, an account extended public key with receive and change branches and a wildcard index, and an eight character checksum. — Key material is abbreviated here and the checksum is illustrative, but the shape is exact. Copy yours out of your coordinator in full, characters and all, and store it with every seed backup.Original diagram by BTCLinks, from the Bitcoin Core descriptor documentation and BIP-48.

Two details in that string repay attention. The bracketed prefix, [73c5da0a/48h/0h/0h/2h], is the key origin: a master fingerprint so a device can tell whether a key is its own, then the BIP-48 path where multisig accounts live. Script type 2h is native SegWit and is what you want; 1h is the older nested form. And the eight characters after the hash are a checksum that catches up to four substitutions in a descriptor up to 501 characters long, which is exactly the protection you need for something you may one day transcribe by hand from a piece of paper.

Setting one up, step by step

The specifics vary by coordinator, but the sequence does not.

Initialise each device separately. Each generates its own seed, on its own hardware, and shows you its own words. Never let one device generate keys for another.
Back up each seed before going further. Steel, one location each, tested. The cold storage guide covers why paper is a bad bet and why aluminium plates melt below house-fire temperature.
Export the account xpub from every device at the BIP-48 native SegWit path, m/48'/0'/0'/2'. Most devices offer this as a QR code or a file on a microSD card. This is public data, so exporting it is not a risk.
Import all N xpubs into the coordinator and set the threshold. It will produce the descriptor.
Register the descriptor back onto each signing device. Skipping this is a classic mistake. A device that does not know the wallet cannot show you a trustworthy change address, so it cannot warn you when malware quietly redirects your change to itself.
Write the descriptor down N times and store one copy alongside each seed backup. Plain text. No abbreviations.
Do a full recovery drill on a trivial amount before funding it properly. Wipe the coordinator, rebuild from the descriptor and two devices, and spend a few thousand satoshis back out. Until you have done this, you have a hypothesis rather than a wallet.

Step seven is the one that separates a working setup from a hopeful one, and it is also the only step that costs nothing but an evening.

What a 2-of-3 multisig wallet survives, by what you have lost
What you lost	Can you still spend?	What to do
One key, descriptor intact	Yes	Sign with the other two, then move everything to a fresh wallet.
Two keys, descriptor intact	No	Nothing. This is the case 3-of-5 exists to survive.
The coordinator laptop	Yes	Install any compatible coordinator, import the descriptor.
Firmware wiped on one device	Yes	Restore that device from its own seed backup.
The descriptor, all three keys held	Maybe	Some coordinators rebuild it if you know the quorum and paths. Do not plan on it.
The descriptor and one key	Probably not	Two keys left and no record of how they combine. Treat as lost.

Read the last two rows against the first. Losing a key is a recoverable inconvenience; losing the descriptor turns a recoverable inconvenience into a permanent one.Table by BTCLinks.

How does signing work once it is set up?

Through a partially signed Bitcoin transaction, which BIP-174 standardised so that a Trezor and a Coldcard could cooperate on one spend without either vendor writing code about the other. The file moves through six defined roles.

Six numbered PSBT stages in two rows. Creator builds the unsigned transaction, Updater attaches previous outputs and key paths, Signer signs on each device independently, Combiner merges the signed copies, Input finalizer assembles the witness once the quorum is met, Transaction extractor emits the raw transaction. A footer gives the magic bytes 70 73 62 74 FF and notes the file is not secret before signing. — Each stage can happen on a different machine, days apart. The Signer role never sees another participant's private key and does not need to, which is the property that makes geographic separation practical.Original diagram by BTCLinks, from BIP-174.

In practice: the coordinator builds a PSBT, you carry it to device one on a microSD card or as a sequence of QR codes, device one shows you the destination and amount on its own screen and signs, you carry it to device two, and the coordinator finalises and broadcasts. Nothing in that file is secret before it is signed, so an air-gapped transfer carries no risk of leaking a key. That is by design, and it is why air-gapped multisig is genuinely workable rather than merely theoretical.

Verify the destination address on each device's screen. Every device. The reason your computer has a screen you cannot trust is covered in our guide to common Bitcoin scams, and multisig does not exempt you from it.

What registering the descriptor actually prevents

Step five above sounds like bookkeeping. It is not, and the attack it blocks is worth spelling out because it is invisible if you skip it.

When you spend part of a balance, the remainder comes back to a change address your wallet generates. You never see that address, you never check it, and you have no reason to think about it. Now suppose the machine running your coordinator is compromised. It builds a PSBT that pays your intended recipient correctly, and quietly sets the change output to an address the attacker controls. Your signing device shows you the recipient and the amount. Both are right. You approve, and the change, which might be most of the balance, is gone.

What a signing device can verify with and without the wallet descriptor registered
On the device screen	Descriptor not registered	Descriptor registered
Recipient address	Shown, and you check it	Shown, and you check it
Amount and fee	Shown	Shown
Change address	Just another address, or not shown at all	Recognised as yours, or flagged
Change quietly redirected	Undetectable	Caught before you approve

The bottom row is the entire argument for a step that looks like paperwork. Everything else on the screen is identical, which is exactly why the omission goes unnoticed until it costs something.Table by BTCLinks.

A device that holds the registered descriptor can compute every legitimate change address itself, so it recognises the one in front of it as belonging to the wallet or flags it as foreign. A device that has never been told the wallet exists cannot tell the difference and shows you nothing. That is the entire reason the registration step exists, and it is why doing it again after a firmware update matters: some devices lose the registration when the firmware is replaced.

Why are the keys sorted?

Because order changes the script, and a different script is a different address. Feed three keys to two wallets that order them differently and the two disagree about where your coins live, which looks exactly like losing them.

BIP-67 fixes this by requiring compressed keys sorted lexicographically by their binary representation. The BIP's own framing of the problem is the useful part: without a convention, a given key set and threshold could produce as many as 2(n!) valid redeem scripts, each with its own P2SH address. In descriptor terms this is the difference between multi(), where order is significant, and sortedmulti(), which reorders for you. Use sortedmulti().

The multi and sortedmulti descriptor functions compared
	`multi(k, ...)`	`sortedmulti(k, ...)`
Key order	Significant, exactly as written	Sorted lexicographically for you
Same keys, two wallets	Can produce different addresses	Always the same address
Follows BIP-67	No	Yes
Reach for it when	A script needs one exact order	Essentially always

If you are ever handed a set of keys and asked to rebuild a wallet, this is the first thing to establish, because picking the wrong one produces a valid wallet at the wrong addresses.Table by BTCLinks, from the Bitcoin Core descriptor documentation and BIP-67.

BIP-67 is also honest about its own limits, and this is worth internalising: it "is not technically possible to enforce as a rule on the network," because a P2SH address reveals nothing about the script behind it. Sorting is a convention wallets agree to keep. It is not a rule anyone checks.

Where do multisig setups actually fail?

Not in the cryptography, and not to attackers. The recurring list is administrative, which is a polite way of saying it is boredom.

Common multisig failure modes and the practice that prevents each one
What goes wrong	What it costs	Prevention
Descriptor never backed up	Everything. Keys become scrap.	One written copy stored with every seed backup.
Descriptor not registered on the devices	No trustworthy change verification.	Register before funding, and after any firmware update.
All keys in one building	One fire or burglary takes the quorum.	One key per location, minimum. Geography is the point.
Recovery never rehearsed	Discovering the gap on the worst day.	Full drill on a small amount, repeated after changes.
Same vendor for every device	One firmware flaw reaches the whole quorum.	At least two manufacturers across N.
Nobody else can operate it	Coins die with you.	Written instructions. See inheritance planning.
Coordinator treated as the wallet	Panic when the vendor shuts down.	Your descriptor plus any compatible coordinator rebuilds it.

Every row is cheap to prevent and impossible to fix afterwards, which is the same shape as most self-custody losses. The last row is the one that causes needless panic: coordinators are interchangeable, descriptors are not.Table by BTCLinks.

If you need something for the descriptor and the seeds themselves, plain stamping hardware is ordinary kit and buying it from a marketplace is fine: stainless steel seed backup plates on Amazon. The signing devices themselves are the one category where that is a bad idea.

Should you use multisig at all?

Here is the argument against, made properly, because you will not hear it from anyone selling a multisig product.

Multisig removes two single points of failure and adds three new obligations: a descriptor that must survive, N devices whose firmware must stay current, and a recovery procedure complicated enough that your family will not manage it without written help. For a balance you could rebuild in a year of saving, that trade is bad. One hardware wallet, one tested steel backup, one off-site copy, and you are done thinking about it.

When multisig is worth the complexity, by amount held
Roughly how much	What we would run	Why
Money you would shrug off	A reputable phone wallet	Multisig here is theatre with extra steps.
Meaningful, replaceable	One hardware wallet, steel backup, off-site copy	Fewer moving parts means fewer things to get wrong.
You have started losing sleep	2-of-3, two vendors, three buildings	The single seed has become the thing you worry about.
Life-changing	2-of-3 with a professional co-signer, or 3-of-5	Someone who can help your heirs, without custody.
Shared or organisational	Quorum matching who must agree	The threshold is now a governance decision.

The third row is the real trigger, and it is a feeling rather than a number: the moment the single point of failure is what you think about at night, you have outgrown it.Table by BTCLinks.

The fourth row deserves a word, because collaborative custody is the option most people have not considered and it solves a specific problem. In that arrangement you hold two keys and a company holds the third. Two of three still spend, so the company cannot move your coins alone and cannot stop you moving them either. What it can do is help when something goes wrong: reconstruct a wallet after you lose a device, and give your family a phone number to call rather than a puzzle to solve. You are paying a subscription to keep a competent party in the quorum. That is a fair trade for some people and an unnecessary dependency for others, and the honest test is whether anyone in your household could recover the wallet without it.

One last note on cost, because it cuts against the usual assumption that multisig is expensive to spend from. It used to be. A Taproot key-path spend of an aggregated arrangement is 57.5 vbytes, the same as any single-signature Taproot input, and it looks identical on chain. Multisig support in Taproot wallets is still patchier than P2WSH, so most setups in 2026 are still wsh(), but the fee penalty for holding coins this way is closing.

Whatever you build, verify it against your own node rather than a company's server. Our guide to running a full node covers that, and custodial versus non-custodial wallets is the right place to start if you are still deciding whether self-custody is for you at all.

Sources

BIP-11: M-of-N Standard Transactions. Source of the m {pubkey}...{pubkey} n OP_CHECKMULTISIG form, the leading OP_0 and the OP_CHECKMULTISIG stack bug, and the standardness limit of n no greater than 3. Verified 2026-07-29.
BIP-67: Deterministic Pay-to-script-hash multi-signature addresses. Source of the lexicographic sort of compressed keys, the 2(n!) figure, and the statement that the convention cannot be enforced as a network rule. Verified 2026-07-29.
BIP-174: Partially Signed Bitcoin Transaction Format. Source of the six roles, the magic bytes 0x70 0x73 0x62 0x74 0xFF, the .psbt extension and the base64 encoding. Verified 2026-07-29.
BIP-48: Multi-Script Hierarchy for Multi-Sig Wallets. Source of the m/48'/coin'/account'/script_type' path and the script type values 1' for P2SH-P2WSH and 2' for P2WSH. Verified 2026-07-29.
Bitcoin Core: Support for Output Descriptors. Source of the multi() versus sortedmulti() distinction, wsh(), and the checksum detecting up to 4 substitutions in descriptors up to 501 characters. Verified 2026-07-29.
Bitcoin Core, src/script/script.h. Source of MAX_PUBKEYS_PER_MULTISIG = 20 and MAX_SCRIPT_ELEMENT_SIZE = 520, from which the 15-of-15 P2SH ceiling follows. Verified 2026-07-29.
Bitcoin Core, src/policy/policy.h. Source of MAX_STANDARD_P2WSH_SCRIPT_SIZE = 3600 and MAX_STANDARD_P2WSH_STACK_ITEMS = 100. Verified 2026-07-29.
Bitcoin Optech: Preparing for Taproot. Source of the 57.5 vbyte Taproot key-path input figure. Verified 2026-07-29.

Some links are affiliate links. As an Amazon Associate we earn from qualifying purchases. We do not link hardware wallets on marketplaces; buy those direct from the manufacturer. Not financial advice.