On-chain or Lightning
Not understanding what I’m about to explain is risky if you are making a multisignature wallet. Make sure you understand everything.
This can be difficult to explain succinctly and clearly, but I’ll give it a shot.
To begin, it’s very important to clarify some definitions:
Individual keys – An individual private key creates a public key which creates an address. Nothing else. In the early days of Bitcoin, all keys were individual, so the term “individual” was superfluous. Every time you wanted a new address, you’d have to create a private key, then from it a public key, and from that an address. It gets very tedious to do that securely. Address reuse was common practice.
Today, after the development of “hierarchical deterministic wallets” (see below), when using the term “private key” or “public key” it can be ambiguous, as it may mean “individual private/public key” (Prv Key / Pub Key) or “extended private/public key” (xPrv / xPub).
HD Wallets and Extended keys – With the introduction of BIP32 (Bitcoin Improvement Proposal 32), a user could create a single private key, called an “extended” private key. From this key, many individual private keys are automatically (and deterministically) generated. In this way, a user can have virtually limitless individual private/public key pairs from a single secret. An extended private key, in addition to creating limitless individual private keys, can create an extended public key. The extended public key creates limitless individual public keys. These keys are identical to the ones created via the extended private key.
A picture tells a thousand words (follow colour coded paths):
Seed – I will use this term to mean “seed phrase”, or “mnemonic words”, because on its own, “seed” is a little ambiguous – it can mean a seed phrase or an extended private/public key. From the seed phrase, you can generate your extended public and private key pairs. These two keys “belong” to the seed, and only this exact seed can generate this exact key pair. If you lose the seed, you lose the extended Private AND Public keys (If you don’t have backups of those).
Note the generation of these keys is one-way, meaning you can’t calculate the seed from the keys.
Extended Private Key (xPrv) – This is a string of characters (that represent a large number). It can be used to create the Extended Public Key. If you lose the private key, you also lose the ability to create the public key.
The two xPUBs in the image above are the same.
Extended Public Key (xPub) – This is a string of characters (that represent a large number). It is needed to create the wallet (unique collection of addresses). If you can’t create a wallet, you can’t spend bitcoin held by the wallet. If you lose the extended public key, you can generate it from the extended private key, or seed.
The above schema is for a single signature watching wallet (watching refers to the fact that you can see addresses, but can’t spend bitcoin from them).
The schema below is for a single-signature spendable wallet (The seed is the same, so the addresses are the same). Focus on the differences between the two images – the green arrow indicates how the addresses are created:
This is the schema for a multisignature watching wallet (can see addresses, but can’t spend bitcoin):
The important thing to take from this is that ALL 5 xPUBs are required to generate the wallet (wallet = collection of unique addresses). You can get the xPUB from the corresponding xPRV or the corresponding seed, but you MUST have the xPUB, or you lose your wallet and the bitcoin it contains, regardless of your key spending threshold.
The key spending threshold of say 3 of 5, means that you can lose 2 of the extended private keys, and you can still spend your bitcoin, PROVIDED YOU CAN GENERATE YOUR WALLET – AND FOR THAT YOU NEED ALL 5 PUBLIC KEYS.
What’s the point of a 3 of 5 threshold then, if you can’t “safely” lose 2 keys?
To answer this, you have to think about what you are storing. You might choose to store each SEED in a separate physical location, thinking if one or two locations are compromised/destroyed, you won’t lose your bitcoin. But this is true only if you don’t also back up all the public keys with plenty of redundancy. For example, in each of the 5 locations, you would store all the public keys. Like this…
Now, if you lose access to two locations, you can still generate the wallet:
This schema shows how you can regenerate the wallet as a watching wallet (no spending) with 5 xPUBS:
And this schema shows how you can regenerate the wallet as a spending wallet (includes 3 private keys which come from the seed). Pay attention to the seed/key numbers:
The important difference here is that because seed 1 and seed 2 are lost, we can use one of the redundant backups of xPUB1 and xPUB2 which would normally come from seed 1 & 2. For signers 3, 4 and 5, we can contribute to the generation of the wallet with the seeds (which contains the private keys) instead of the xPUB, to make this a spending wallet.
The above wallet is spendable, even though two seeds are lost, because we created the wallet as a 3 of 5 multisignature wallet.
Put in other words, if you have a 3 of 5 multisignature wallet, if you don’t separately back up all the xPUBs, you effectively have a 5 of 5 multisignature wallet in terms of STORAGE RISK (not losing your bitcoin, ie recreating your wallet). In terms of SIGNING, it’s still a 3 or 5 wallet.
Splitting the wallets
Here’s an interesting thing you can do with multisignature:
Both computer 1 and computer 2 have watching-only wallets, but between them, they have 3 private keys.
To spend, we generate a transaction in computer 1, save it, and transport the partially signed transaction to computer 2.
Computer 2 now holds a transaction with the signatures from seed/private-key 1 & 2, and it adds the signature from seed/private-key 3. The transaction is now valid and can be broadcasted to the Bitcoin Node network.
Offline signing
For extra security, you can keep computers 1 and 2 completely offline and air-gapped, never ever to be exposed to the internet. This keeps the private keys safer.
Because these computers have no access to a network, they don’t have access to the blockchain, so the balance will always be shown as zero, even if the address are associated with bitcoins. Because there are no UTXOs to spend (as seen from the offline wallet), a transaction can not be generated.
We need an online version of the wallet to generate an unsigned transaction, which we can then pass to the offline computers for signing (This can be done by QR code which is the safest way and maintains the air-gap; a USB drive transfer is also possible but introduces risk as it breaks the air gap).
What Next?
If you feel like you’ve absorbed this information, you’re ready to practice building a multisignature wallet – you can follow this guide.
Tips:
Static Lightning Address: dandysack84@walletofsatoshi.com
On-chain or Lightning