You have decided to do it. Now what?
It describes kinds of setups, not companies.
| Document | multivendor-multisig-for-a-single-holder.md |
|---|---|
| Version | 0.5 — draft |
| Audience | People who hold their own bitcoin and have decided on a multivendor multisig: read Start here, then §2 to §10 as the job reaches each step. Technical reviewers: read the full note and its References. |
| Method | Take the setup as it is usually pitched: several keys, devices from different makers, backups in different places. Write down every thing a single holder has to make, place, check, and keep doing for the pitch’s promises to hold. Tie each step to the promise it serves. |
| Changes | See the changelog. |
| Scope | One holder, a plain 2-of-3 or 3-of-5 multisig, no other spending paths, no other people. Written for signing devices; §1.2 covers signing with software instead. Not a review method: for that, see Who Can Move Your Bitcoin?. Not a ranking of setups or devices. |
This section is for anyone who has decided to hold bitcoin in a “multivendor multisig, keys in different places” setup. You do not need technical knowledge to use it.
What the words mean. Secret numbers called keys control bitcoin. A multisig wallet has several keys and needs some of them to spend. “2-of-3” means three keys exist and any two can spend. “Multivendor” means the keys live on signing devices from different makers. “Keys in different places” means the backups of the keys are stored apart, so that one fire or one burglary does not reach them all.
What the pitch promises. The pitch makes three promises:
What it actually takes. Each promise holds only if you do the work behind it. In a solo setup, nobody else makes, stores, checks, or uses the keys. The job is:
2-of-3 or 3-of-5? More keys do not give you more protection unless you also use more places, more trips, and more practice. A 3-of-5 kept in three places protects against lost places no better than a 2-of-3 kept in three places. The table in §3 shows why.
Signing with software only. Some setups use no signing devices. One wallet program, on computers kept offline, makes every key and signs. That is the opposite of multivendor: one program instead of several makers. The third promise then rests on that one program. Several steps change too: how the keys are made, what the backups are, and where you read before you sign. See §1.2.
What this note does not do. It does not say that multisig is right for you, or name any device or company. It does not cover inheritance, sharing keys with family, or wallets with timed recovery paths. Adding any other person or company to the setup changes what each promise depends on. See §1. It lists the work so you can see the whole job before you start.
The note covers one holder and a plain threshold multisig: t of n keys can spend, and the wallet has no other spending path. It covers 2-of-3 and 3-of-5, written as wsh(sortedmulti(...)) descriptors. Multisig descriptors (BIP 383)
The pitch is a set of promises about a deployment. The protocol enforces only the threshold: the output can be spent by valid signatures from t of the listed keys. Where the keys are, who made the devices, and whether the holder can reach them are not things the protocol checks. They are the holder’s job, and that job is what this note describes.
Adding another person changes the setup, whoever they are. A person or company becomes part of the setup if they hold a key, backup words, a copy of the setup record, or access to a place. What they can do depends on what they hold. With t keys, they can spend. With fewer, they can refuse, delay, or lose what they hold. They can also be the route by which a thief, or someone forcing a spend, reaches it. Each promise in Start here then depends partly on that party: their honesty, their security, their availability, and whether they still exist when needed. This is true whether the party is a relative, a friend, a lawyer, or a company that holds a key as a service. A party can also add a recovery route that the holder does not have alone. Whether that trade is worth making is the holder’s decision. The custody note covers how to review it. Scenario B, §4
When the setup stops being solo. These are common ways another party joins. Each one changes the setup as the paragraph above describes. This note does not cover how to set any of them up.
The mechanisms behind each step are described in more detail in Who Can Move Your Bitcoin?. That note is a method for reviewing a custody claim. This note is the work list for one person who builds the setup. Where a step rests on a mechanism, the section links to the custody note or to the specification.
The note makes no claim about how often any step fails. It does not say that a setup that follows every step is safe. It says what each promise depends on.
| Term | Meaning here |
|---|---|
| Holder | The one person whose bitcoin it is, and who does every step in this note. |
| Key | A private key that can sign for the wallet. A 2-of-3 has three keys. |
| Backup words | The written words (a BIP 39 mnemonic) from which a device can make the same key again. A backup is a copy of a key: whoever has the words has the key. Mnemonic to seed (BIP 39) |
| Signing device | A small device that makes a key, stores it, and signs with it. A device that stores a key is a copy of that key, protected by the device’s PIN and its maker’s design. |
| Device maker | The company that designs a signing device and its software. This note calls them Maker A, Maker B, and Maker C. “Multivendor” in the pitch means devices from more than one device maker. |
| Place | A location where one or more copies of keys are stored: a home, a safe in another building, a deposit box. Two places are separate only if one event (a fire, a burglary, a move) cannot reach both. |
| Setup record | The wallet descriptor: a short text that lists every key’s public part, where each key came from, the threshold, and the address type. A wallet needs it to find and spend the coins. See §4. Descriptor format (BIP 380) |
| Coordinator | The wallet app on the holder’s computer or phone. It builds the wallet from the setup record, shows the balance, and builds transactions for the devices to sign. It touches every key’s public part and every transaction. |
| Unsigned transaction | A file (a PSBT) that carries a payment from the coordinator to each device, and carries each device’s signature back. Partially signed transaction format (BIP 174) |
| Signing program | A wallet program on a computer that makes keys, holds them, and signs, used in place of signing devices. See §1.2. |
Some setups use no signing devices. One wallet program, run on dedicated computers kept offline, makes every key and signs. Its pitch is the opposite of “multivendor”: fewer parties and fewer programs, instead of several makers. The rest of this note is written for signing devices. The table shows which steps change when the signer is a program.
| Step | With signing devices | With one signing program |
|---|---|---|
| The third promise (§5, §10) | A defect in one maker’s device reaches only the keys on that maker’s devices, if no maker’s devices hold t keys. | One program touches every key, so a defect in it can reach all n keys at once. The promise becomes a claim about that one program: who reviewed it, and who else rebuilt it. Put the §10 questions to the program and its publisher. Shared components |
| Making keys (§5 step 3) | Each device makes its own key. | Often all keys are made on one computer in one session. The keys are separate, but one defect or one compromised session at creation can affect all of them. Making keys on more than one offline computer narrows that. Key independence |
| Backups (§4, §5 steps 4 and 9) | Backup words (BIP 39) on durable material. | Often the program’s own key files on durable media, with no backup words. A file that holds a private key is a copy of that key, as backup words are. Restoring needs a program that reads those files and a drive that reads the media. Test a restore with a fresh copy of the program, and refresh the media on a schedule. |
| Spending (§6) | Carry the unsigned transaction to each device, or bring the keys together. | Often t key files are loaded into one offline computer for one session. That is the “bring the keys together” case: that place and that computer hold t keys until the session ends. Loading one key per session, and carrying the transaction between sessions, avoids it at the cost of more sessions. |
| What to read (§5 step 7, §6) | Each device’s own screen, with the wallet registered on the device. | The offline computer’s screen, after it decodes the transaction. No separate device checks the online computer’s work, so the offline computer is both the signer and the checker. Wallet registration (BIP 388) does not apply. Before you sign, check how the program shows the address, amount, fee, and change. |
| Upkeep (§8) | Each device’s updates, on each maker’s schedule. | One program and its operating system, on each computer. Each update is a new release of that program to check. Three checks |
The two columns put the same promises on different things to check. This note does not rank them.
A setup can also mix the two, with some keys on devices and some in a program. Apply each column to its own keys. Count a program that holds several keys as you would count a maker whose devices hold several keys (§5 step 2).
For a plain t-of-n wallet with separate keys and the setup record available:
| 2-of-3 | 3-of-5 | |
|---|---|---|
| Keys needed to spend | 2 | 3 |
| Keys you can lose and still spend | 1 | 2 |
| Keys a thief needs | 2 | 3 |
| Keys left to you after a thief gets enough to spend | 1, too few to move the coins first | 2, too few to move the coins first |
| Devices to buy, set up, and update | 3 | 5 |
| Backups to make and store | 3 | 5 |
These counts hold only while the setup record survives (§4) and only while the keys are truly separate (§5). They count keys, not places. A promise about places depends on where the keys are, which §3 covers. The custody note gives the general rule. Independence and quorum size
In both setups, a thief who gets enough keys to spend leaves you too few to race them. The only defense against theft is that the thief never reaches t keys.
Count every copy. Each key can exist in more than one copy: the backup words, and the device that stores the key. List each place and every copy in it. A place holds a key if any copy of that key is there.
The two rules.
Keep each device with its own backup, or count the key twice. A device at home and its backup words at Place 2 put the same key in two places. That helps against loss, because both copies must be lost. It hurts against theft, because either copy gives the key.
What the places give you. In these examples each key is in exactly one place. Each place holds no more than t−1 keys, and a copy of the setup record:
| Setup | Keys per place | Places a thief must reach | Places you can lose and still spend |
|---|---|---|---|
| 2-of-3 in 3 places | 1, 1, 1 | 2 | 1 |
| 3-of-5 in 3 places | 2, 2, 1 | 2 | 1 |
| 3-of-5 in 4 places | 2, 1, 1, 1 | 2 | 1 |
| 3-of-5 in 5 places | 1, 1, 1, 1, 1 | 3 | 2 |
The arithmetic follows from §2. A 3-of-5 in fewer than five places gives the same protection against lost and broken-into places as a 2-of-3 in three. It still covers more losses of single copies, such as one set of backup words that is damaged while its place is fine. With one place per key, the extra protection against places comes only with five separate places.
Copies of keys in more places. Keeping a key in two places changes these counts. It can let a setup survive more lost places, but each extra copy is one more place a thief can take that key from, and one more place to visit and check.
| Setup, any two places lost | Keys per place | Places a thief must reach |
|---|---|---|
| 2-of-3, one place per key | Not possible: losing two of three places leaves one key | — |
| 2-of-3 in 5 places, with copies | A, A, B, B, C | 2 |
| 3-of-5, one place per key, 5 places | A, B, C, D, E | 3 |
| 3-of-5 in 4 places, with copies | A; B and C; B and D; B and E | 2 |
Five places is the fewest for a 2-of-3 that survives any two lost places. Four places is the fewest for a 3-of-5, and only with copies. A 3-of-5 that survives any two lost places and still needs a thief to reach three places takes five separate places.
Passphrases change the counts too. With a passphrase on a key (§5 step 5), the key is usable only with both its backup words and its passphrase. Each key then depends on two items, and where they are stored changes what the places give you. For a 2-of-3 with a passphrase on every key, each item stored once:
| Where the passphrases are | Places | Places you can lose and still spend | Places a thief must reach |
|---|---|---|---|
| No passphrases | 3 | 1 | 2 |
| Each passphrase with its own words | 3 | 1 | 2 |
| Each passphrase with the next key’s words (A’s passphrase with B’s words, B’s with C’s, C’s with A’s) | 3 | 0: losing any one place leaves one usable key | 3 |
| A’s words and passphrase together; B’s words, B’s passphrase, C’s words, and C’s passphrase each in a place of their own | 5 | 1 | 3 |
The third row is the usual advice, to keep each passphrase away from its own words. It makes a thief reach every place, and it means one lost place locks the coins. Keeping the loss protection while making a thief reach three places takes at least five places. No layout in three or four places does both.
A passphrase kept only in your memory is not in any place a burglar can reach. It is lost if you forget it, and it is reachable by anyone who can make you tell it. An heir cannot recover a key whose passphrase only you knew.
What makes places separate. For each pair of places, ask what single event reaches both: the same building, the same street in a flood, the same household, the same person with keys to both. A place you cannot reach for a month, such as a box at a bank that has closed for a holiday, is a place you have lost for that month.
Places that belong to someone else. A deposit box, or a drawer at a relative’s house, is a place where another person controls access. With fewer than t keys there, that person cannot spend. They can refuse or delay your access, and a thief who gets into their place gets that key. Count it as a place that can be lost or broken into, and record who controls access. §1 covers what any added party changes.
Distance has a cost. The farther apart the places are, the longer a spend takes (§6), and the harder a check of each place is (§8). Pick distances you can travel to when you need to, including when you are ill or away.
What it is. The setup record lists every key’s public part (an xpub), each key’s fingerprint and derivation path, the threshold, and the address type. With it, any compatible coordinator can rebuild the wallet. Descriptor format (BIP 380)
Why the backups are not enough without it. Backup words make one key. They do not say which wallet the key belongs to, which other keys are in it, or how many must sign. BIP 380 states the problem for any wallet restored from its keys alone: “it is not possible for restored wallets to know which kinds of output scripts and addresses to produce.” Descriptor format (BIP 380)
In a 2-of-3, two sets of backup words give two keys, but not the public part of the third key. Every address uses all three public parts. So two backups, without the setup record and without the third backup, cannot rebuild the addresses, even though two keys are enough to sign. Before deciding that the coins are lost, look for every other record of the third key’s public part: another copy of the setup record, a coordinator export, or a wallet stored on a device. Wallet metadata
How many copies. The setup record has to survive every loss the setup plans for. Keeping it in one separate place adds a single place whose loss, together with one key, can lock the wallet. One way to meet the rule is a copy with each set of backup words.
What a copy costs. The setup record does not let anyone spend, but it lets anyone who reads it see every address in the wallet, and so the balance and the payment history. A thief who finds one place learns the balance as well as one key. Weigh that against the risk of losing the wallet, and record the choice. Extended keys and privacy (BIP 32), Multisig descriptors (BIP 383)
Make it complete. Check that the copy includes each key’s fingerprint and path, not only the xpubs. BIP 48 sets out a common path for multisig keys, m/48'/0'/0'/2' for this address type. A common path does not prove that a given wallet used it, so record the path the wallet actually used. Multisig derivation (BIP 48)
Check that it works. A copy you have never rebuilt the wallet from is a copy you have not checked. §7 includes this.
Do these steps in order, with a small amount of bitcoin, before you move savings into the wallet.
What “multivendor” does and does not cover. Devices from different makers mean that a defect in one maker’s device or software reaches only the keys on that maker’s devices. That protects the wallet only while those keys number fewer than t (step 2). The coordinator is not one of the devices. It reaches every key’s public part and every transaction. If you approve what the computer shows instead of what each device shows, one bad computer, or one bad coordinator update, can mislead every device at once. The protection comes from reading each device’s own screen at setup (step 7) and at every spend (§6). Shared components
Choosing and keeping the coordinator. The coordinator is a program like any other, and it touches every key’s public part and every transaction. Four things to settle about it:
To spend, you need signatures from t devices. With the keys in different places, there are two ways to get them.
Carry the unsigned transaction. The coordinator makes an unsigned transaction. You take it, on a memory card or as QR codes, to each place in turn, and the device there adds its signature. Back home, the coordinator combines the signatures and sends the transaction. The format is built for this: a device that signs it does not need to be online, and the file carries what the device needs. The keys never leave their places. The file does show the payment and parts of the wallet, so treat it as private. Partially signed transaction format (BIP 174)
Bring the keys together. You bring t devices, or t sets of backup words, to one place, sign, and take them back. This is quicker. While they are together, that one place holds enough keys to spend. Record where they meet and for how long. Signing location and exposure
What a spend costs in travel. If home is one of the places, a 2-of-3 spend is one trip to a second place. A 3-of-5 spend is two trips. A spend you need on short notice depends on reaching those places on short notice.
Spending often. Every spend costs t signatures, and so t places reached. If you expect to spend often, that cost comes with each spend. Some holders keep a separate, smaller wallet with one key for spending, and refill it from the multisig now and then. The multisig then signs only the refills. That second wallet is a separate setup with its own backup, and this note does not cover it.
The fee is fixed when you sign. A signed transaction carries its fee. If it is stuck because the fee was too low, both ways to raise the fee need the wallet’s signatures. One is a replacement with a higher fee, signed again by t keys. The other is a second transaction that spends the change, which is in the multisig and needs t keys too. Either way, a stuck payment can cost another round of trips. Set the fee for the confirmation time you need when you sign. The person you paid can also raise the fee by spending what they received, if they are willing. Whether nodes accept a replacement depends on their relay rules, which are not part of consensus. Fees and deadlines, Opt-in replacement signaling (BIP 125)
Each deposit is a separate coin. Every payment into the wallet becomes a separate coin to spend later. A multisig spend reveals t signatures and all n public keys for each coin it spends, so it is larger than a single-key spend, and a 3-of-5 spend is larger than a 2-of-3 spend. A spend that uses many small coins costs more in fees than one that uses a few large ones. Combining small coins into one, when fees are low, lowers later costs. It also costs a spend now, with its trips, and it shows publicly that those coins belong together. Spend-time policy disclosure, Multisig descriptors (BIP 383), Transaction cost
What to read on each device. At each signature, read the device’s screen: the address you are paying, the amount, the fee, and whether the change goes back to the same wallet. The device shows you what it signs, and the coordinator may not. Wallet policies (BIP 388), Signer policy validation
Someone forcing you to spend. In a solo setup you alone can reach t keys. A person who forces you to spend can get what you can get. Distance can slow a forced spend, and it slows your own spends by the same amount. Privacy and coercion
A step that has not been practiced is a step you do not know works. Practice with a small amount, before the wallet holds savings, and again after anything in §8 changes.
Regular upkeep.
When something is lost. After losing one key in a 2-of-3, you can still spend, with no spare. Losing one more locks the coins. Make a new wallet with new keys, and move the coins to it while you still have t keys. If only one copy of a key is lost, such as its backup words while its device still works, ask whether someone else could have found it. If they could, treat that key as stolen. Rotation and exit
When something may be stolen. If one place may have been broken into, treat its keys and its setup record as taken. The thief now needs t keys minus the ones they have. Move the coins to a new wallet before they reach another place.
Old backups. After moving to a new wallet, the old backup words and old setup record still control any coins at the old addresses. Decide what to do with them, and check that the old wallet is empty.
| 2-of-3 | 3-of-5 | |
|---|---|---|
| Makers whose claims you checked (§10) | 3 | At least 3 |
| Devices, so no maker holds t keys | 3, one each from Makers A, B, C | 5, from at least 3 makers, no more than 2 from one |
| Sets of backup words | 3 | 5 |
| Items to store, with a passphrase on every key | 6: words and passphrase for each key (§3) | 10 |
| Copies of the setup record | One with each set of backup words, or enough to survive every planned loss | Same |
| Places, so no place holds t keys | At least 3 | At least 3 |
| Places, so any two can be lost | With one place per key: not possible. With copies: 5, and a thief needs 2 (§3) | With one place per key: 5, and a thief needs 3. With copies: 4, and a thief needs 2 (§3) |
| Trips per spend, if home is one place | 1, and another round if a fee has to be raised (§6) | 2, and another round if a fee has to be raised |
| Checks on each device’s screen at setup | Threshold, fingerprints, first address | Same |
| Practice spends with a place missing | 3, one per place | One for each planned loss |
| Upkeep | 3 devices to update, 3 places to visit | 5 devices to update, up to 5 places to visit |
The third promise of the pitch rests on the device makers. You choose Maker A because of what Maker A says: about its keys, its software, its backups, its multisig support. Each claim you rely on is a claim to check before Maker A’s device goes into the wallet. The other more eyes notes are written for that check. This section points to them. The last two rows are claims a coordinator’s publisher makes. If you sign with a program instead of devices (§1.2), put the same questions to that program and its publisher. The release note’s questions apply directly.
How to judge an answer. A good answer shows you something you can open: a document, a signed file, a build report, a test you ran yourself. A weak answer repeats the claim in different words. A weak answer does not prove a problem. It shows that the claim is not established yet. Makers publish different things, so expect different answers from Maker A, Maker B, and Maker C.
| If the maker claims | Ask for | Read more |
|---|---|---|
| Keys never leave the device | What crosses the cable, card, or QR codes in each direction. Every backup, export, and debug path, and whether any of them puts a key outside the device. A key can also leak through signatures without leaving as a key. | Custody note §6, §3 |
| Air-gapped | Which medium carries data to and from the device. A card or QR code changes how data crosses, not whether it crosses. | Custody note §1.2, transfer channel |
| The device shows you what you sign | A demonstration, for this multisig address type, that the device shows the threshold and every key’s fingerprint at setup, and the address, amount, fee, and change at each spend. Run it yourself in §5 before funding. | Custody note §6, Scenario D, Wallet policies (BIP 388) |
| Works with any multisig wallet | Whether it signs a wsh(sortedmulti(...)) wallet, exports its xpub with fingerprint and path, signs unsigned transactions (PSBTs), and registers the wallet. Test it with your coordinator. |
Scenario D |
| Standard backup, restore anywhere | Whether the backup is standard BIP 39 words. A restore of the same words on another maker’s device that gives the same fingerprint. If there are no words, what the backup is and what reads it. | §5 step 9, Custody note §6, Mnemonic to seed (BIP 39) |
| Open source | The tag or commit the firmware you install was built from, and the public history behind it. A license does not identify the file you install. | Release note §6 |
| Reproducible or verified firmware | Which of the four levels of build evidence is shown, for the firmware actually on the device, and by whom. A second builder’s signed report of the same hash. | Custody note §6, Release note §2 |
| Signed firmware and updates | What the signature covers, how you tie the key to the maker, and who can sign an update. | Release note §6, Custody note §3 |
| Keys come from a true hardware random source | The build setting and the function that key creation calls, and a check that fails if another source is used. Code that is present is not proof that it runs. | Which Code Actually Runs? §6 |
| Built on a well-reviewed library | Which library and version, how it was obtained, and which implementation inside it does the job. | Which Code Actually Runs? §2, the embit note as a worked example |
| Audited | The report: its subject, scope, date, and exclusions. A code review and a security test of one model answer different questions. | Custody note §1.1 |
| We never see your keys (a coordinator) | Which server the coordinator talks to, what it sends there (addresses, xpubs, transactions), and what that server keeps. Not seeing keys is not the same as not seeing the wallet. | §5, Custody note §5 |
| Works with any device (a coordinator) | Which address types, wallet registration flows, and file formats it supports, tested with your devices before funding. | §5, Scenario D |
Put the same questions to each maker. A maker whose answers you have checked still covers only the keys on its own devices (§5). The shared parts, such as the coordinator and the places, are checked in the other sections of this note.
wsh(sortedmulti(...)) wallet with no other spending path. It does not cover Taproot wallets, timed recovery paths, keys held by a service or by other people, or inheritance. For those, see Who Can Move Your Bitcoin?.Unresolved.
Each source is listed once with the version consulted and the sections that cite it. The BIPs were read on 23 October 2026 at the commit given, the same commit the custody note cites.
| Reference | What it defines | Cited in |
|---|---|---|
| BIP 32 | Hierarchical Deterministic Wallets: extended keys, and what sharing an extended public key reveals | §4, §5 |
| BIP 39 | Mnemonic code for generating deterministic keys, including the optional passphrase | §1.1, §5, §10 |
| BIP 48 | Multi-Script Hierarchy for Multi-Sig Wallets: the m/48' derivation path and script type levels |
§4 |
| BIP 125 | Opt-in Full Replace-by-Fee Signaling: the rules for replacing an unconfirmed transaction with a higher-fee one | §6 |
| BIP 174 | Partially Signed Bitcoin Transaction format and its roles | §1.1, §5, §6 |
| BIP 380 | Output Script Descriptors: general format, and key origin information | §1.1, §4, §5 |
| BIP 383 | Multisig Output Script Descriptors: multi() and sortedmulti() |
§1, §4, §6 |
| BIP 388 | Wallet Policies for Descriptor Wallets, including policy registration on a signing device | §5, §6, §10 |
| Who Can Move Your Bitcoin? | Review method; Scenario D (holder-controlled 2-of-3); the custody lifecycle; independence and quorum size; coercion; questions for device claims | §1, §1.2, §2, §3, §4, §5, §6, §8, §10, §11 |
| What Can You Check About a Software Release? | The three checks, and questions for release claims | §1.2, §5, §10 |
| Which Code Actually Runs? | Fallbacks in software that makes or uses keys, and questions for those claims | §10 |
| What Can You Check About an embit Release? | A worked example of the release questions put to one library | §10 |
Newest first. Versioning follows STYLE.md. Version tags use the prefix multisig-v, and each released version links to its tagged text.
| Version | Change |
|---|---|
| 0.5 — 23 October 2026 | Practical gaps. §3 adds passphrase placements for a 2-of-3: the usual advice to store each passphrase away from its own words leaves no place that can be lost, and keeping that protection while making a thief reach three places takes five places. §5 adds choosing and keeping the coordinator, and extends step 5. §6 adds spending often, fees fixed at signing (raising one takes t signatures again), and coin count and size. §1 lists common ways a setup stops being solo, with links to the custody note. Start here, §8, §9, §10, limits, Unresolved, and References updated. Adds BIP 125. |
| 0.4 — 23 October 2026 | Adds §1.2, which shows which steps change when one wallet program on offline computers signs instead of signing devices: the third promise, making keys, backups, spending, what to read, and upkeep. Adds a Start here paragraph, a Signing program term in §1.1, a line in §10, and a scope line. Unresolved records that no software-only setup was run. Does not rank the two. |
| 0.3 — 23 October 2026 | Review fixes. §3 states that its first table puts each key in one place, and adds a table for copies of keys: a 2-of-3 survives any two lost places in five places with copies, and a 3-of-5 in four places with copies, each with a thief needing two places. The §9 row for two lost places now carries the one-place-per-key condition. Unresolved records how the counts were checked. |
| 0.2 — 23 October 2026 | First release. The work a single holder does to set up, place, spend from, practice, and keep up a plain 2-of-3 or 3-of-5 multisig with devices from different makers, and questions to put to each device maker that point to the other notes. Names no device or company. The text is the 0.1 draft with only the version line and this changelog changed. |
| 0.1 — 23 October 2026 | Not released. The tag multisig-v0.1 was created on commit fc1ee71 before the note was merged, and does not contain this note. Tags are not moved or deleted, so the note is released as 0.2. |