Multi-key
Several keys, a set number of which must sign: how it works on BSV without P2SH, and the three jobs it is good at.
One key is a single point of failure in both directions: lose it and the money is gone, leak it and the money is gone. Multi-key removes that by requiring several keys to agree, so no single loss and no single theft is enough.
It costs speed. Every payment needs more than one action, often on more than one device, sometimes by more than one person. That makes it right for money that moves rarely and wrong for money that moves daily.
How it works on BSV
The spending condition is written into the output's locking script: n of these m public keys must sign. BSV uses bare multisig, where the keys sit in the output script itself.
No P2SH
New pay-to-script-hash outputs are not allowed on BSV, so the pattern of hiding a script behind a hash and revealing it at spend time is not available. The keys are visible in the output from the start. Plan for that: a multi-key output announces that it is one, and how many keys it needs.
A second approach avoids the script entirely. Split one key into shares (BRC-140) and require a threshold to rebuild it before signing. The output then looks like any other single-key output.
| Bare multisig | Split key (BRC-140) | |
|---|---|---|
| Visible on chain | Yes, keys and threshold | No, looks like a single key |
| All keys in one place at any point | Never | Yes, at the moment of signing |
| Signers act | Independently, in any order | Together, or through a coordinator |
| Fits | Shared control between parties who do not fully trust each other | Backup and inheritance for one owner |
Recommendation
Pick on the trust question, not the privacy one. If the parties need to be sure no one of them can ever reconstruct the whole key, that is bare multisig. If the goal is one person's key surviving a fire, shares are simpler and cheaper.
The three jobs it does well
Savings that one stolen phone cannot reach
Two of three keys: the phone, a signing device, and one kept offline. A thief with the phone has one key and no money. The owner who loses the phone still has two. See Savings wallet.
Money more than one person controls
A business account where two of three directors must approve, or a shared household fund. The approval is enforced by the script, not by a policy somebody can ignore.
Do
Show whose signature is still outstanding, and give a way to nudge them. Most of the time a shared payment is waiting on a person, not on the network.
A plan for what happens after
Keys distributed so that the owner can spend alone today, and named people can recover together later. See Inheritance wallet.
Designing it
Setting up
Setup is the hard part, and the part people abandon. Each key has to be created, stored somewhere different, and recorded so it can be found again.
Do
Walk the setup one key at a time, and say for each one where it is going and what losing it would mean.
Do
Let an unfinished setup be saved and resumed. Gathering three devices or three people rarely happens in one sitting.
Don't
Finish setup without the user having restored from it once. An untested multi-key wallet is a wallet with more ways to fail than a single-key one.
The wallet configuration is itself a backup item
A multi-key wallet needs more than its keys to recover: it needs to know which public keys are in the set, the threshold, and the script. Lose that and a quorum of keys still cannot spend.
The configuration also names every participating key, so it maps the whole arrangement. Do not put it somewhere public to keep it safe.
Do
Back up the wallet configuration with the same care as a key. It names every key in the arrangement.
Signing
Progress matters as much as the request: "two of three collected, waiting on the third".
Do
Show what is being signed in plain terms on every device that signs, and how many signatures are collected.
Do
Let a partly signed payment be abandoned cleanly, without leaving funds stuck.
Saying it in the interface
Users name their keys in their own terms, such as "This phone", "Signing device" or "Kept at home". Use those names.
Don't
Say "2-of-3 multisig". Say "Two of your three keys are needed to spend", and name the keys the way the user named them.
Pros and cons
Pros
- One lost key does not lose the money.
- One stolen key does not spend the money.
- Shared control is enforced by the script, not by trust.
Cons
- Setup is long, and easy to abandon.
- Every payment needs several actions.
- The configuration is one more thing to back up, and losing it strands the funds.
- Bare multisig is visible on chain, including the threshold.
Related
- Overview: the four schemes compared
- Spending conditions: multi-key scripts
- External signers: often one of the keys
- Savings wallet
- Shared wallet
- Inheritance wallet
Written from: BRC-42, BRC-140, ts-stack script docs.
Checklist
The rules on this page, in a form you can work through.
9 rules