Two-of-three multisig: What happens if a key is lost?

What the two-of-three rule means

Call three independent keys A, B and C. In this educational example, signatures from A and B, A and C, or B and C satisfy the policy. There are three possible pairs. This is a simple model, not a description of every contract or product using the multisig label.

Independence concerns the keys and who controls them. Restoring the same recovery phrase onto three devices may give every device access to the same key authority. It does not create three independent cosigners. Similarly, one person controlling two independent keys can meet this example’s threshold without involving the third person.

The arrangement can distribute spending authority and tolerate some loss, but the intended benefits depend on placement and control. Count neither devices nor people without first mapping which keys they can actually use and recover. A numerical label alone does not describe the complete custody arrangement.

What changes when one key disappears?

If A is lost while B and C remain usable, a route satisfying the example policy still exists. Usable means more than knowing where two devices are stored. You need to unlock or recover them, reconstruct the right wallet and prepare requests they can sign through supported tools.

Distinguish a failed local device from loss of every usable copy of its key. A valid independent backup may preserve the key after hardware failure. Conversely, a device in a box is not practically available if its required access information and recovery route are both missing.

After loss, review whether the key was destroyed, merely unavailable, or potentially exposed to another party. Those scenarios differ. Changing the arrangement or moving funds has product-specific steps and possible transaction costs; editing a cosigner’s display name does not necessarily alter the actual spending policy.

Loss and control scenarios

Back up the policy as well as the secrets

Depending on the wallet, reconstruction may require cosigner public keys, spending policy, derivation paths, address type and other setup information. Possessing two private secrets does not imply software can infer every original configuration choice.

The Electrum multisig documentation demonstrates exchanging cosigner public data and checking that participants derive matching receiving addresses. That is an example of the configuration work involved, not a reason to assume every multisig product uses an identical recovery format.

Public setup information is not a spending key, but it can expose financial relationships and transaction visibility. Preserve access for the appropriate participants without publishing account labels and all partner data unnecessarily. A recovery plan must balance availability and privacy rather than treating every non-secret field as public information.

Example: three devices across two locations

Suppose Salim puts A and B, together with their backups, in one office and keeps C at home. He counts three devices and two locations. An office fire may nevertheless remove two signing routes at once, leaving only C in this simple example.

The useful test is loss of a whole location, including backups stored there. For each imagined event, list the keys and required configuration information that remain. Then determine whether a valid signing pair can still be operated. This exposes shared dependencies that a device count conceals.

In another arrangement all three backups are accessible through one cloud account managed by one person. The visible distribution may look broad while access still depends on one account. Review the event that can affect multiple components together, including travel, temporary storage and maintenance sessions.

How to test without destroying a working route

Start by writing the intended policy, each participant’s role and the required reconstruction data. Use the product’s appropriate learning environment or a deliberately limited setup after understanding network and fee behavior. Testing should not require erasing the only working copy of a key.

Compare receiving addresses through the supported verification process. Matching file names or wallet labels do not prove participants built the same account. If addresses differ, stop and resolve the configuration before placing substantial value under the arrangement.

Next review a clear transaction: destination, amount, fee and change output where applicable. Each signer should understand the request being approved. Two signatures on a wrong transaction do not become a correct payment merely because they meet the threshold.

Finally rehearse an absent participant scenario on paper and, where appropriate, through a supported non-destructive test. Record what the exercise established and what it did not. Being able to construct a wallet is different from proving you can recover and operate it after a specific failure.

Does multisig always cost more?

There is no universal percentage surcharge attached to the name. Transaction size and fee behavior depend on the actual construction, output types and product. Review the estimate for the particular transaction instead of copying an old comparison and applying it to every two-of-three setup.

There are also operational costs: coordination, tool maintenance, policy backups and recovery testing. These may matter more than a single transaction fee. A simpler arrangement can be easier for one user to operate consistently, while another user needs genuine separation of authority across participants.

Questions that determine readiness

Who can sign today, and who can recover each key? What happens if one participant is unavailable for an extended period? Which event could remove two keys at once? Where is reconstruction information, and how do participants verify they are approving the same transaction?

Write executable answers rather than relying on the phrase two of three. The threshold helps only when the intended routes remain available and control remains distributed as planned. Our backup testing guide helps distinguish an inventory check from a demonstrated recovery path.

Continue reading