I've received many questions from people considering to set up a #Bitcoin multisig wallet but confused about the backup process, what should be backed up, and why.
🧵So here's a thread on backing up multisig wallets - what, why, and how.
The main caveat in a multisig wallet is that, while you need only a threshold of devices (ie. 2 of 3, 3 of 5, etc.) to sign a transaction, losing access to even a single device could potentially prevent you from being able to spend the funds - if you don't back up properly!
The reason is that (usually) in order to make a Bitcoin transaction, it is not enough to be able to sign it, but you also need to provide the "terms for spending", that is, the Script (code) that is used to lock the coins.
That's because the full script is usually not stored directly on the blockchain, but only as a hash (a unique identifier of it).
Then on spending, you need to provide both the original script code which matches that hash, and satisfy any condition that the script may include.
In a single key wallet, this is trivial.
The script is composed of the public key of your wallet and a few standard commands - and satisfying it requires the signature for that key, so both the script and signature can be constructed by having access to that one private key.
With a multisig, this is not the case. The script for a multisig contains the list of public keys of all possible cosigners - which means it can be constructed only by knowing the public keys of ALL devices in the multisig, not just of the devices you are signing with.
To demonstrate, let's assume a 2 of 3 multisig. When you want to get an address of your multisig, your wallet software is taking the public keys of all 3 cosigners, lists them in a standard way inside a script, hashes it, then with this hash constructs the address.
When receiving bitcoin to that address, there is a "commitment" on the blockchain for all 3 public keys, out of which 2 signatures are needed. But the public keys themselves are not listed yet on the blockchain - you must provide them too when spending from the address.
Now assuming you have lost access to one private key (a device and its mnemonic backup), you won't be able to tell its public key anymore - so you won't be able to reconstruct the script of the address. So even though you have enough signatures, you won't be able to access funds.
The solution - which is the extra step of a multisig backup - is to also keep a backup of the list of public keys (xpubs) of all cosigners, from which you will be able to recreate the script.
Since this list of public keys does not contain signing (private) keys, there is no risk of losing funds even if an attacker manages to access it, but this would be a privacy concern since the attacker will then be able to see the balance on the multisig wallet.
That's why it is not recommended to leave this file on some cloud backup or some other insecure option.
It's recommended that you keep it with each one of the cosigners/ seed backups so that you can recover regardless of the combination of signers you eventually use.
Besides the list of public keys, it is also necessary to know the script type used (whatever native SegWit, nested SegWit, or legacy), and the threshold chosen in order to construct the multisig script. These are possible to know by guessing (brute force), but better keep it too.
The last piece which you should include is the derivation paths used for each device. Each derivation path tells your wallet how to turn each master public key, into a different individual "disposable" public key used to generate every new address.
This data of derivation paths is standardized so that all wallets should use the same derivation path by default, but it is best to keep that around too especially if you use a unique one for some reason.
This might sound like a lot of components, but to simplify usage, there’s a standard for storing and recovering such information, which is called Output Descriptors.
Just as an example of what the final backup might look like, here are a few pics of a PDF backup generated from @SpecterWallet
This contains the individual devices keys list, as well as everything in an output descriptor format (and a bit of extra data like wallet name etc.)
You could save this by simply printing the PDF, storing it on an SD card, or just keep it encrypted on a cloud backup. What you need to remember is: 1. You need this information to recover the wallet. 2. Anyone with access to this information can see your wallet history.
So to simply sum it up, the additional piece you should backup when using a multisig wallet is the output descriptor - a list of the public keys of the cosigners with some data on the wallet.
This information is possible to derive only with access to all devices in your multisig and is necessary to spend from it.
So to remove the single point of failure of losing access to one cosigner, you should keep this backup along with each of your devices. fin/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I’ve received many questions about full nodes. What is a full node, what it does, and what’s so important about it? So here’s a thread for anyone wondering why they should run their own #Bitcoin full node? 🧵👇
1/ Let's start with what is a full node? In simple terms, it's not very different from a database, mapping bitcoins to their owners. Every #Bitcoin transaction updates the current state of the database, deleting the old owners and assigning the new ones.
2/ To stay up to date with the latest changes, the node communicates in a "peer to peer network" with other nodes and asks them for new transactions and blocks.
1/ When using #Bitcoin, there are generally 3 components involved:
- Private keys
- Signing device
- Wallet software
The differences between these can be confusing, but knowing them is important in order to understand the best practices in self-custody (🧵thread).
2/ Your private keys, often represented as a list of 24 words, are the secret information you need to prove that you know in order to sign transactions.
Anyone holding your private keys can spend your coins, which is why you must handle them as securely as possible.
3/ The private keys are used to derive #Bitcoin addresses, which the user can receive funds to.
Then, they're used again to produce a digital signatures for these derived addresses, when the user wants to spend the coins received.
I've received many questions lately, but by far the most common question is “What's the best way to secure #Bittcoin?”
🧵So here’s a thread with my opinion on securing #Bitcoin
The first thing to understand is that there’s no "best way", but always a tradeoff.
You can always find ways to make it harder for someone to get your #Bitcoin, but if you over-complicate it, you could end up making it even too hard for yourself - many lost their funds this way.
Your goal should be to balance usability and security the way which works best for you.
This means very different things for different people, depending on your technical experience, understanding of Bitcoin, how much you are holding, etc.
“Early in life I have noticed that no event is ever correctly reported in a newspaper, but in Spain, for the first time, I saw newspaper reports which did not bear any relation to the facts, not even the relationship which is implied in an ordinary lie. I saw great
battles reported where there had been no fighting, and complete silence where hundreds of men had been killed. I saw troops who had fought bravely denounced as cowards and traitors, and others who had never seen a shot fired hailed as heroes of imaginary victories; and
I saw newspapers in London retailing these lies and eager intellectuals building emotional superstructures over events that never happened. I saw, in fact, history being written not in terms of what happened but of what ought to have happened according to various party lines.”
- Massive refactoring of the history and UTXO tabs!
- Export transactions, UTXO, and addresses to CSV
- Address labeling from anywhere
- New Tor configurations page
- New testing framework github.com/cryptoadvance/…
Highlights (2/3)
- Search, sort, and more in the transactions and UTXO tables
- Export historical prices of transactions to CSV
- Support all Tor features by having the Tor Browser open
- Tor-only option for any external requests
- Add UTXO tab to wallets overview
Highlights (3/3)
- Option to automatically generate a self-signed SSL certificate
- Fix Electrum export for signing with Coldcard
- Lots more bug fixes and improvements