Multisig protects bitcoin by requiring signatures from several designated keys before it can be spent. Under a 2-of-3 rule, any two of three distinct keys suffice. Losing one need not mean losing the money, and a thief with just one key cannot spend it. This depends on proper backups and genuinely separate keys.
Alice does not want all her savings to depend on one device. She creates a 2-of-3 wallet with independent keys A, B and C. A payment can be approved by A + B, A + C or B + C. Each signature is mathematically verifiable authorization produced by the relevant private key; the key itself is not sent to the network. If she loses A, she can still use B and C, provided she also has the necessary wallet information. Someone who steals only A cannot send the money alone. The bitcoin is not divided into three piles: the shared rule protects the funds concerned as a whole. Three people can hold the keys, or one person can hold them on separate devices. Three copies of the same Seed Phrase, the same set of backup words, do not create three independent keys. [1] [2]
Alice enters the recipient’s address and amount in an app. Acting as a coordinator, the app prepares a proposed transaction and passes it to the signing devices. It often uses PSBT, a format for carrying the payment details and the signatures added along the way. The devices therefore need not be connected at the same time or kept in the same place, and private keys remain separate. Before signing, Alice checks the recipient, amount and fee on the trusted display of each device she uses. Using the verified wallet policy, the device should also recognize the output returning any change to her. Two signatures on a fraudulent payment will not protect her. The coordinator cannot invent a missing signature, but it can present a bad proposal. Only after obtaining the required signatures and finalizing the transaction does the app broadcast it. [5]
Each independent key needs its own secure backup. Two sets of backup words alone are not necessarily enough to recover the entire wallet. It also requires the shared configuration: the signature threshold, public information for all three keys, their order and the way addresses are generated. This can be stored as an Output Descriptor, a precise technical description of the wallet, or an equivalent configuration export. A public descriptor without private keys cannot sign a payment by itself, but it can expose addresses and money flows, so it also deserves privacy. Alice first tests receiving, sending and recovery with a small amount. If she later loses key A or suspects it has leaked, removing the device from the app does not change the old rule. She must use the remaining keys to move the funds to newly verified addresses with a new set of keys. [4] [6]
A 2-of-3 rule tolerates losing one key; a 2-of-2 rule tolerates losing none. With the first rule, any pair can also spend, including two people acting without the third. The right setup therefore depends on whose money it protects and which failures it should withstand. If Alice stores every device and backup in the same drawer, one theft or fire can defeat their separation. Checking payments, wallet compatibility and recovery also take more work. The spending conditions here are expressed in a script, a short program. A conventional script-based multisig transaction usually occupies more space than a comparable single-signature transaction and therefore costs more at the same fee rate. For a beginner, a well-understood simple wallet can be safer than a complicated setup they do not understand. [1] [2]
The general expression m-of-n means that m valid signatures are required from n designated keys. In conventional script-based Multisig, the public keys and this threshold form part of the spending condition. A transaction output specifies that condition directly or commits cryptographically to the relevant script. When it is spent, nodes, the computers that check Bitcoin’s rules, verify the required signatures and script data; this is more than permission from an app. In descriptors, multi preserves the supplied public-key order, while sortedmulti sorts keys by a precise rule. A derivation path tells the wallet which specific keys to calculate from its starting key material. Incorrect ordering or different derivation paths can produce different addresses. The descriptor lets a wallet reconstruct those conditions; it is not itself stored on the blockchain as a configuration file. This explanation covers conventional script-based Multisig. Other constructions can combine several participants behind one joint signature and have their own rules. [3] [4] [7]
A 2-of-3 policy
Multisig with three distinct keys requires valid signatures from any two. One stolen key alone is insufficient; after losing one, the other two can spend if the required script data is also available. Separate keys and their backups, and retain the complete Output Descriptor or equivalent wallet policy.
For the clearest picture, read this entry together with Private Key, Wallet, PSBT. The reverse links also lead from HD Wallet, Cold Storage, Watch-only Wallet, Change Address.
01Is Multisig automatically safer than one Hardware Wallet?+
No. Properly separated keys and backups can reduce a single point of failure, but more participants add operational complexity. A verified wallet policy and tested recovery are needed; a compromised shared coordinator can present the same wrong payment to everyone.
02Must all Multisig keys be in one place for signing?+
No. PSBT lets participants exchange data and signatures separately without collecting private keys. Each signer should verify recipients, amounts and the fee. Before broadcast, the transaction must be finalized with the required valid signatures and meet all other input conditions.