New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
BTCJP's preserved multisig note describes a two-signature arrangement with three cosigners, combining a software wallet and hardware devices. The saved interface belongs to its historical period, but the underlying design question remains useful: which combinations of people and equipment should be able to authorise a payment? Answering that question requires more than selecting two-of-three in a setup wizard. The wallet also needs a reproducible configuration, a review process and a recovery policy. This new laboratory guide develops those requirements through hypothetical arrangements. It does not reproduce the old interface as a current installation tutorial or endorse the particular devices named in the source.
Write down what the threshold is meant to survive
In a hypothetical two-of-three arrangement, any two of three distinct signing keys satisfy the intended threshold. That creates flexibility after losing access to one signer, but it also means any authorised pair can act without the third. These are two consequences of the same rule. Begin by stating the intended failure: a broken device, an unavailable colleague or the loss of one location. Then state the unwanted authority: one person acting alone, for example. The threshold should be evaluated against both statements rather than chosen because its numbers sound reassuring.
Consider three cases on paper. One signer is temporarily unavailable; one signer permanently loses its secret; two signers become controlled by the same person. The first two concern recovery, while the third concerns authority. A design can handle one well and the other poorly. Record which cases the proposed arrangement actually addresses and which remain outside it. This produces a policy that can be discussed before funds depend on it. It also helps distinguish a deliberate shared-control arrangement from a collection of spare devices that all remain accessible through the same account.
Different devices are not necessarily independent signers
Signer independence concerns the secret and the control path, not simply the number of physical devices. Two devices restored from the same signing secret do not become two independent cosigners merely because their cases are different. Likewise, three separate secrets stored in one easily accessible file can create a shared failure point. The relevant question is what an unavailable or compromised component would expose. A policy review should follow the actual custody of each secret and the permissions that allow a person to use it.
For a hypothetical organisation, map each signer to an operator, a storage location and its recovery material. Then check the overlaps. Perhaps the same administrator controls access to two backups, or the same office incident would remove every device. These observations do not determine one universal storage arrangement. They identify whether the claimed independence exists under the event the policy is intended to survive. A practical review is specific: it explains what remains possible after a defined failure instead of treating different product names as proof of independent control.
Keep the wallet description as well as the secrets
Recovering a multisig wallet involves knowing how its signing keys are combined. Bitcoin Core's descriptor documentation describes a language for representing sets of output scripts, including multisig constructions. The broader operational point is that a secret and a wallet configuration answer different questions. The secret enables a signer to participate; the configuration identifies the relevant policy and the outputs being watched. A recovery plan should not assume that finding one backup phrase automatically reconstructs every cosigner relationship, derivation detail and script choice used by the original arrangement.
Create an inventory of the information needed to reproduce the chosen wallet in its actual implementation. Separate public configuration from material that can authorise spending, while recognising that public wallet information can still reveal sensitive financial relationships. Record the software and format used to export the configuration. The goal is a reproducible description, not an indiscriminate bundle of credentials. Someone carrying out the recovery exercise should be able to explain which information reconstructs the wallet's view and which additional authority is required to approve a transaction.
Reconstruct the same view before testing a payment
Electrum's multisig documentation includes checking that participating wallets derive the same receiving addresses. This is an important boundary: several devices can appear to be configured successfully while not describing the same wallet. In a laboratory exercise, compare the relevant public configuration and independently derived addresses before interpreting a displayed balance or preparing a transaction. A disagreement here is a configuration problem to resolve, not a reason to proceed and hope that the different views will converge after a payment has been attempted.
Document what constitutes a successful reconstruction. A useful test might require a clean installation to reproduce a set of known laboratory addresses and identify a known test transaction. Retain the configuration version and the expected result so another authorised person can repeat the exercise. This is more informative than a photograph of a setup screen saying complete. The photograph records a moment in one interface; the reconstruction demonstrates that the retained information can recover the intended view when the original working environment is no longer available.
Separate preparing, reviewing and signing
A shared signing policy does not automatically create a shared understanding of the transaction being signed. Someone may prepare a payment, another person may review it and several devices may provide signatures. These are distinct activities. The review should establish the intended destination, amount, network fee and change handling in the context of the wallet's implementation. Each signer needs an account of what it is approving. Merely receiving a file from a colleague does not establish that the file matches the payment the group intended to make.
Use a hypothetical payment request to rehearse the handoff. Record the request, compare it with the prepared transaction and identify where each reviewer observes the consequential details. Introduce a deliberate mismatch in a laboratory setting and check whether the process catches it. The point is not to invent a perfect human procedure. It is to determine whether the extra signatures add independent review or simply repeat one person's unexamined decision. A threshold provides an authority rule; the operating procedure determines how people exercise that authority.
Rehearse the difficult day without relying on memory
A recovery exercise should start from the conditions it claims to test. If the original coordinator is supposed to be unavailable, that person should not quietly supply missing configuration from memory. If one device is considered lost, the exercise should not use it halfway through. Keep a record of every missing dependency discovered during the rehearsal. These findings are the useful output. They show which part of the plan depends on an undocumented password, a particular computer or a colleague who happens to remember how the wallet was first assembled.
The historical BTCJP note is valuable as a record of an early practical experiment. A current companion explanation can carry its central question further: what happens when a signer fails? Define the intended authority, examine independence, retain the wallet description and rehearse reconstruction and review. Revisit the plan after personnel, devices or software change. A multisig arrangement becomes an operating system for shared authority only when its recovery and approval paths can be explained and repeated, not merely when a setup screen displays the desired number of cosigners.
Technical references
From the recovered archive
- Bitcoin: Multisig Wallet, Electrum with LedgerNano and Keepkey · captured 2 March 2021