Skip to content Link Search Menu Expand Document Video
Examples of locations for storing multiple private keys.

Multi-key

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.

Tip

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.

How it works

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.

Pros
  • 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
Cons
  • Has significant complexity and op-sec burden for multiple private keys, each of which needs a good backup scheme
  • Not compatible with lightning node wallets

General user flow

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.

Diagram of Alice, Robert, and Charles generating private and public keys

Then, they exchange the public keys, so each of them has a set of all 3.

Diagram of the three wallet owners exchanging public keys

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).

Diagram of each wallet owner constructing the multi-key wallet

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.

Diagram of Alice intiating a transaction and Robert signing it

Best practices

When to use

  • When storing large amounts
  • When funds need to be accessed by several people or an organization
  • When target audience is likely to own hardware wallets
  • When users are likely to be very knowledgeable or be guided through setup and use
  • When most users are likely to implement good backup schemes for multiple keys

When not to use

  • For small amounts
  • When users are likely to be new to bitcoin
  • When controlling a lightning node

Variations

  • Number of total and co-signing keys
  • Key storage devices and distribution
  • Managed or completely self-managed

Do’s

  • Make sure the multi-key setup itself is backed up properly, including extended public keys for all the participating keys, fingerprint and derivation.

Products that use this scheme

Next, we do a technical deep dive into how transactions on bitcoin work.