All of the previous schemes have relied on a single private key to control the wallet. This presents an all-or-nothing risk for loss of funds from both theft and negligence. To counter this, a wallet can have several private keys attached of which all or a subset need to sign any transactions.
This is often called multi-signature, or multi-sig for short, but is also sometimes referred to as a vault. A multi-key setup is described as m-of-n to indicate how many keys are needed to sign a transaction out of the issued number. For example, a 2-of-3 setup requires two of the three private keys to sign a transaction for it to be valid.
In the case of a personal wallet, one individual will control all the keys but hold them on different devices for increased security. See the savings wallet reference design for a UX exploration of this use case.
In the case of a shared wallet, different people will control the keys. The number of keys and required co-signers will depend on the use case. With spouses sharing a joint account, a simple 1-of-2 multi-key setup might suffice, meaning there are two keys but only one is required to sign for a transaction to be valid. At the other end of the spectrum, a company might require a more complex 3-of-5 setup, requiring three of the five co-signers to approve any transaction.
It is important to remember that the usage of multiple keys is necessary only for signing outgoing transactions, but not for receiving funds. This is a common misunderstanding.
A multi-key scheme can raise the security, since anyone needs access to more than one key to move any funds. But clearly, it also increases complexity and requires the user(s) to keep even more keys securely stored and/or backed up.
The keys used by a lightning node cannot be controlled by a multi-key setup, as they need to be continuously available to the node.
A software wallet application or coordination software initiates a multi-key wallet, choosing the number of total keys, and the number required to sign transactions. You then add extended public keys from other wallets generated elsewhere to the multisig after which the software wallet can complete the creation process, and start generating addresses. For any future transaction from the multi-key wallet, the required amount of co-signers need to sign (using Partially Signed Bitcoin Transactions) before any transaction is valid.
It is possible to configure a wallet with multiple sets of keys, with each having its own spending rules. Find out more in the custom spending conditions page.
Significantly increases security against theft
Can allow several people to access and control a shared wallet
Can tailor requirements for multiple co-signing and access situations
Has significant complexity and op-sec burden for multiple private keys, each of which needs a good backup scheme
Alice, Robert, and Charles want to set up a multi-key wallet that has a total of 3 keys, with 2 keys required to send a transaction.
In the first step, each of them independently generates a private key and a public key (technically an extended public key). All 3 public keys together are used to construct the multi-key wallet, for generating addresses to receive bitcoin to, and by extension also for constructing new transactions. The private key is never shared, and used to approve transactions, initiated by themselves or others.
Then, they exchange the public keys, so each of them has a set of all 3.
They can now individually construct the same multi-key wallet with the 3 public keys and the spending conditions they decided on (2-of-3). Addresses generated by each wallet will be identical. The order of the public keys is important. A different order will result in a different wallet (for signing, the order does not matter).
Now Alice wants to send bitcoin received to the shared wallet. She can initiate transactions, and sign them with her own key. But she needs another signature for the bitcoin network to accept the transaction. She sends the transaction to Robert, who signs it, and broadcasts it to the network. She could also have asked Charles to do this.