Name: Michael Flaxman

Topic: 10x your Bitcoin security with Multisig

Location: Stephan Livera Podcast

Date: September 28th 2020

Audio: https://stephanlivera.com/episode/215/

Previous SLP episode with Michael Flaxman: https://diyhpl.us/wiki/transcripts/stephan-livera-podcast/2019-08-08-michael-flaxman/

10x Security Bitcoin Guide: https://btcguide.github.io/

Transcript completed by: Stephan Livera Edited by: Michael Folkson

# 10x Security Bitcoin Guide

Stephan Livera (SL): Michael, welcome back to the show.

Michael Flaxman (MF): It’s great to be here. I’m a big fan of the podcast so I love to be on it.

SL: Michael, your first appearance on the show was a very, very popular episode and I think a lot of people took it as a bit of a nightmare episode despite the cautions and saying “Let’s take an incremental approach to this.” Today we’ve got a really interesting topic and material to talk about. So you’ve written this guide. What was the motivation for this [guide](https://btcguide.github.io/)?

MF: So there’s two main parts to it. One is the general idea that we think of Bitcoin as being the best money in human history but the narrative is that it’s really hard to secure. We have these properties of money, it’s scarce, portable, divisible, verifiable and Bitcoin should be more securable. We’ve seen Vijay talk about this a little bit in the idea of censorship resistance as a new criteria to evaluate money on. Every money before Bitcoin was equally censorable. Bitcoin is new in the sense that you can send it across the world and no one can stop you. But we also have security as a new consideration and Bitcoin is the most securable asset in human history. You can’t 3-of-5 your gold. You can’t 3-of-5 anything that’s physical. But you can do that with Bitcoin and you can interact directly with Bitcoin scripting language on the blockchain in a way that is truly magical. We’ll go into more detail about what that means. But it’s really one of the great features of this asset that I think has historically been a negative and in the future should be seen as a positive, that we’ve hit that inflection point. From a practical perspective I’ve just been obsessed with this problem for seven years now. My first Pycoin commit, a Python Bitcoin library in 2013 was on the source of randomness for new wallet creation. Securing Bitcoin is an obsession to me because it’s so terrifying. If you’ve ever sent a large Bitcoin transaction, if you’ve ever moved funds you get the cold storage sweats. It’s a really scary experience that shouldn’t be scary and multisig really does change that equation. We’ll get to that more too. In the most practical sense we did this [episode](https://diyhpl.us/wiki/transcripts/stephan-livera-podcast/2019-08-08-michael-flaxman/) SLP97 last year and I just got hundreds of inbound queries from people saying “Hey, how can I secure my Bitcoin better?” It is amazing that even before I launched this guide that we’re going to talk about today, I was getting messages almost daily since then from people asking questions about their security. I just felt like I had to give people a here’s how you do this guide so that’s what this was born out of. It is pretty neat.

# Fault tolerance

SL: This guide is a great guide and I’ve been a little bit involved here and there. Let’s talk about the motivations with this thing. The key point as a lesson from the earlier episode was around eliminating single points of failure and this concept of fault tolerance. So what’s fault tolerance? Why is that important?

MF: The idea of fault tolerance is that you can have some sort of mistake happen and it can be a really bad one and you can be ok and not lose any money. With security you’re only as strong as your weakest link. So you have to do everything right to secure yourself. Your attacker only needs to find one vulnerability. That’s this huge asymmetry. That’s why we always see bugs in software. And we always will see bugs in software because of this fundamental asymmetry. So much better than trying to be perfect is to be fault tolerant, to allow for some mistakes. To put this in some numbers, we usually use nines in computer science when we talk about uptime or reliability. So if you want to be 90% secure, that’s pretty easy. You can just sort of wander your way into Bitcoin and read some stuff on the internet. Some of it’s probably really bad information, Bitcoiners have gone down this rabbit hole, but you’ll not send your Bitcoin to the wrong person. You’ll not put your seed into a web wallet. You’ll not use a web wallet. You’ll follow these best practices 90 percent of the time. That’s pretty easy. To follow them right 99 percent of the time, that’s much harder. Humans don’t do things like that very often. But you’d be able to figure it out. Then 99.99 or three 9s, that’s pretty difficult. If you want to get to four 9s for a single key that’s very hard. The idea with multisig is instead of being like 99.99, 99.999 percent secure with what you’re doing to guard your setup but doing it all in one key, you have multiple keys and you can be much more casual with each one. So the trade off becomes really, really favorable because you can actually be almost a little reckless in how you set things up and still achieve a far higher level of security. I think it really is the only free lunch. We talk about security and usability being a trade off. That is generally true but multisig is a difference in kind, not degree. It’s truly a one of a kind thing. It’s magical and it’s available to all Bitcoin HODLers. So people should know about it and know it’s available. In the past I’ve made a big point of saying that multisig security is additive. Meaning if you have two keys, A and B, you have the security of both of them added together versus if you were just using A or just using B. In the naive Bayes sense it’s actually multiplicative because the vulnerability you would need to have exploited an A or B in a proper multisig scheme that say requires two signatures, that would have to be exploited in both of them. So if these two vulnerabilities were unrelated then the odds of breaking both of them is now the product of that vulnerability, not the sum. So that is very extreme in terms of additive security. Now we have to assume in the worst case scenario that the vulnerability is the same in both places. And so maybe you’re only 2xing your security. Quantifying this is really, really hard. But the idea is that we move from a model to where you have to get everything right or you can lose money to a model where we say “Here are the things that you have to get right. You have to get 3-of-5 things right. You can make catastrophic mistakes and still not lose money.” That’s a new and fundamentally different model.

SL: Some of this came up in the earlier episode. What is the contributing software and what is the base of it? For example if maybe the different hardware wallets that you’re using, they’re written in different languages, say one is in Python and one is using something else. That would be an example there where if you’re using different kinds of software or different hardware then that’s where you’re getting that multiplicative security benefit right?

MF: Yes. Although I would say that the language it’s written in is very, very low on the risk of things that I would be concerned about for losing money. Let’s talk a little bit about the loss and the cost of these loss to try to put it in perspective. I want to talk about some very specific vulnerabilities that could be catastrophic. At a generic high level, it’s impossible to know how much Bitcoin is lost every year. There are sites that try to track it. But obviously it’s a somewhat unknowable thing. We don’t have a registry of all the Bitcoin holdings and a way to tell when people are saying that Bitcoin is really lost. Obviously there’s already the common meme about private keys being lost in a tragic boating accident. I don’t know if that happened to you but that’s happened to all my Bitcoin. I definitely don’t have any. So we can’t really know. We can look at HODL waves for a sense of when coins are moving and maybe these ones that haven’t moved in so long never will. But even in the most extreme case of that, we have Satoshi’s coins which is an enormous number of coins. We can’t know if those are lost or not. Maybe he, she, or they is just very patient. Maybe they never bothered to record the private keys because 50 Bitcoin block rewards at the time were worth nothing. This was just a neat experiment. Maybe it’s not even lost in the sense that they had been lost. Maybe they never kept them in the first place. But as a general estimate if you ask around, most people would say somewhere between 0.5 percent and 2 percent of all Bitcoin is lost every year. This is truly horrific for HODLers. It’s extra bad because it’s not evenly distributed. So imagine that a 100 percent of HODLers lost on the small end 0.5 percent of their Bitcoin every year. That would be far superior. You don’t want a small chance that you lose it all. You’d rather lose a little bit each year. Of course this is not available to us. It’s not a choice. It’s just the aggregate stat that we have. So if we looked at what this aggregate stat was of say on the low end 0.5 percent per year, that’s sort of an equivalent to 0.5 percent inflation per year. We would not look at that as Bitcoiners and think that’s okay. And again that scenario is much better than what we face because we all have this terrifying fear of losing 100 percent. It’s not that we’re evenly paying this price. Now there is this popular 4chan counter argument that is lost coins reduce the supply and that’s good for the remaining HODLers. This is technically true but really not valid for two reasons. First of all, stolen coins don’t reduce the supply. A lot of the losses are theft. Second of all, it’s terrible PR. Bitcoin’s reputation, part of the reason why I’m doing this podcast is because we have this reputation of being an insecure asset. It keeps people from wanting to buy Bitcoin. Practically speaking those who lose their Bitcoin are unlikely to rebuy it and so it’s really not a good thing to have loss. I wanted to start by zooming out and saying this is the problem that we’re trying to combat. Then maybe I could dive into some of the actual losses and what that looks like.

SL: I guess at a macro level what you’re trying to get out there is essentially people might not feel as comfortable getting started with Bitcoin. Or they might’ve lost some Bitcoin and then not rebought. Maybe the steelman would be something like look longer term. It’s not going to matter. They’re going to have to do it. Maybe the counter of that would be something like “The more we can make this secure the faster we can speed the transition into hyperbitcoinization.” If we’re focused on security and we’re trying to educate ourselves and educate our family and our friends on how to secure our Bitcoins that arguably strengthens the system. Let’s start with some of the single points of failure. You mentioned how it’s very hard to get single signature right? What are some of those factors that make that so?

# Challenges of single signature

MF: I want to start with the one that is absolutely terrifying, that the overwhelming majority of your listeners who use single key setups on their hardware wallets should be very afraid of. Hopefully this will motivate them to make a change. There’s a couple of different things that hardware wallets do. One of the most obvious things that we have to have it do correctly is generate your seed securely. We can think of this as a form of random number generation because your hardware wallet has some sort of random number generator in it. It is using that to generate your 24 word seed. We know that this is really important. We know to guard these. Bitcoiners back them up, maybe they etch it into metal. They know not to share it. But the thing that’s really, really hard to do is to prove a source of randomness. In fact it’s almost impossible to prove, although we’ll talk about a proof that we are using in the multisig setup later. We really can just observe a random number generator. The joke is like if I asked you to pick a number between one in a billion and you had a random number generator that was doing this, and you pick the number 7, I would be pretty confident that your random number generator was broken. I couldn’t prove that, one in a billion times it would pick the number seven, that’s a valid choice. Certainly if I queried your random number generator 10 times and it spit out the number 7 ten times in a row I would say “That’s really really unlikely. How many times does Lightning have to strike in the same spot before you say something about that doesn’t make sense?” But I still couldn’t prove it. It’s still statistically possible. Although at that point we’re at one in a number so big our human brains can’t comprehend. With random number generators, observing whether they’re working correctly or not is in practice very, very hard. Unless you have a way to query it a lot like that. With a hardware wallet that’s not really how it works. You boot it up, you maybe take it out of its packaging, you may plug it in, you go through some steps on screen, the buttons are very slow, you’re setting up a PIN and then it says “Here’s your seed”. By the way you’re not going to buy a hundred thousand of these and test it over and over again. You don’t know about that source of randomness and almost none of these hardware wallets use reproducible builds. There’s no way to know what firmware they’re running. There’s no way to even confirm that if they were using a reproducible build because unless it was with a secure element that you trusted you wouldn’t be able to validate that build. The point being any person at that hardware wallet manufacturer, either upstream where they made it or an employee who put the original software and compiled that to run on that hardware wallet who slipped in a vulnerability could be choosing your seed for you. That would be impossible for you to detect and this would be the ultimate retirement attack. Imagine I create a very reputable hardware wallet company. I run a malicious bit of code. I might even open source my code so you can see what my code does but that’s not the code that I run on that hardware wallet which again you have no way to verify. It spits out your 24 words. You write them down diligently, you’re transacting with them just fine perhaps for years. One day that employee says “All right, I’ve looked at these hardware wallets. I didn’t look at them physically but I’ve looked at the balances that have been accruing on these hardware wallets. It is now say a billion dollars. I’m going to steal it all.” They could do that without ever leaving their home, without ever going into your cold storage. That is truly, truly terrifying in the single key sense. Every single major hardware wallet manufacturer has the ability to have done that for years. We cannot verify this and that attack could take place and it doesn’t have to be malicious on their part. In the paranoid version they could be compelled by a government trying to destroy Bitcoin by getting people to use this. In the much more realistic option, somewhere upstream of them in their supply chain, somebody is clever and saying “I’m going to swap out their use of the random number generator for this seed instead and I’m going to put in my seeds. I’m going to put it in say a billion seeds so that you couldn’t manually detect this.” Back to this example of asking a random number generator and getting the number 7 back. I’ll just put a billion different seeds that are possible under these devices. No two devices will have the same one and I’ll be able to cash them all out at once. Now I don’t think that’s going to happen. It would definitely be bad but the incentive there is so unbelievably strong and we don’t have a way to verify that it’s not going to happen. We only have trust and Bitcoin is about getting away from trust and verifying ourselves.

# Using passphrases and seed pickers

SL: That’s a very scary attack, the long con or the retirement attack. I guess one point that maybe the listener is thinking at this point, Michael, what about passphrases? Do passphrases fix this or not?

MF: So passphrase certainly could. There’s a number of ways to mitigate this attack. I guess maybe we could go through all of them. One of the things to keep in mind is that multisig basically eliminates this class of attack. You could still do this kind of thing. If you’re storing really large amounts with multisig I would recommend you perform one or all of these mitigations. But the beauty of using proper multisig is that you don’t have to think about these kinds of things. I want to stress at each point when we’re going through these what could happen scenarios that if you were doing a 2-of-3 multisig. This only matters if two of your three hardware wallets are using compromised seed generators. If one of them has a compromised random number generator for the seed and two of them don’t there’s no exploit to be had unless you publish your other seed. That is enormously powerful. I want to talk about all the different defenses, what their trade-offs are. But before we do any of that, most importantly, this is all kind of fine if you use proper multisig. This is an example of the type of thing that you can avoid. But going into it. I’ll cut to the best answer and then we’ll work our way backwards to what people do. The best answer would be to be the random number generator yourself. You can’t necessarily prove to anyone else that you’re an unbiased, random number generator but you can prove to yourself that you’re an unbiased, random number generator real easily. The simplest way to do that is to print out your 2048 words and draw them out of a hat. There is a little bit of a complication in there in that the 24th word is a checksum. It doesn’t have to be 24 words by the way. There are people that do shorter seeds. Obviously there’s a security trade-off there but the final word is a checksum. That has to be calculated by computer. That’s pretty annoying. But if you were to pull 23 words out of a hat, use one of these free softwares like [seedpicker](https://github.com/merland/seedpicker) which is one we’ll go over in the future. I publish open source libraries in two different languages, one in Python, one in Golang. Seedpicker is written in Javascript. I believe there are others and I think there will be many others in the future. You can get that 24th word calculated and the xpub that you would need to be able to generate addresses. So if you’re going to do single sig, which I think is only advisable for experts because there’s too many places where you could get it wrong, that is an absolute must. You have to get the random number generation on seed generation correct and you can do it just by pulling words out of a hat. In practice, people don’t want to print out 2048 words, the software libraries aren’t super popular that do this. More likely people are either going to add a passphrase or they’re going to use dice. Those are the two most common ones. If you’re going to use dice you have to verify what you did because there’s two levels of things you’re worried about going wrong. One is the hardware’s random number generator is compromised and the other is that the software is just malware that’s completely lying to you. It doesn’t matter what the hardware random number generator does because it’s just going to spit out the seed that it wants to give you no matter what. So in the case of a compromised random number generator something like rolling dice can work if your software is doing what it’s supposed to be doing. But remember that we’re getting a device shipped to us with software on it that we did not install. It may or may not be doing what the open source published version one says it’s doing. It could be a different version of the software altogether. If we really want to be sure of this then we have to compile our own firmware which is obviously complicated. It requires some command line skills, it is not a recommendable thing for most people. If you’re an expert you might be able to pull off single sig this way. But for a normal user, you just want to buy a device from a company, do some basic validation that it’s real and get about your life. So you’re probably not going to do this. If you’re doing the dice thing and you can trust the firmware, either because you installed it yourself or maybe you bought it from the company at an event, again that trust is only so good because the company doesn’t have to be malicious for this to happen. It could be someone upstream of them in their supply chain that found a way to load this firmware on. It’s a little bit messier but assume that you have good firmware and you want to run this process then if the firmware is really running the software that you think you are then probably you’re just going to be fine. Because it’s going to take your dice rolls and do what’s called in cryptography XOR, or you can think of it as like blending it into the random number. Random numbers are always additive. You can always add two random numbers to one another. The method to add them is usually called XORing the bits together. That’s literally if you have two ones they got to a zero, two zeros go to zero, a one and zero go to a one. Actually I haven’t thought about bit flipping in a long time. Anyway you could XOR bits that way. That’s effectively what you’re doing is you’re just adding two sources of randomness together. If your firmware is good then probably it’s just going to work as designed. Rolling all these dice rolls will work. The scary part is imagine your firmware is actually not doing what you think it’s doing. You roll all these dice and it just ignores all your dice rolls and displays you all this info on the screen that’s irrelevant and then says your seed is good, but actually it’s not. To be sure that your dice rolls worked you have to do it again on another device that you trust and see that the two devices got the same output. Once you get into that land, it’s like if you’re going to use two devices, just do multisig. That’s the whole point. You don’t have to have this level of extreme caution. You can just rely on the security of multisig in the first place. So I don’t love dice. I don’t want to say that they’re terrible but if you’re not doing it again on another device and verifying it then it can be close to borderline security theater. We just like dice because it’s a natural human thing. We see them at casinos and we understand the randomness. But what we don’t understand is that those dice rolls need to map to those words. That’s not something we can manually verify in meatspace. Whereas if we pull the words out ourselves out of a hat then we can verify that those are the words we pulled out. We just need software to tell us that that generates the same addresses which any hardware wallet or software can do for you.

SL: Let me just walk that through in an example. I’m using the Coldcard and I’m doing the dice rolling function where you press four and you roll some dice and it changes the words of your seed. Hypothetically being fully paranoid about this, it’s theoretically possible that the firmware was changed in some way such that you think “It’s showing me new words. Therefore I’ve got a new seed.” But the reality is the guy who was pwning you upstream has set it up such that even though it’s changing the words those are still words that he knows and can use as part of his retirement attack right?

MF: Exactly. It would be trivial for him to have a billion different outputs that he was waiting for. They would look random to you because we went back to this random number generator example where I demonstrate how you can’t prove a random number generator is wrong. But if you have a billion outputs you could spend a lifetime and you won’t be able to prove that that’s not random. You get the same output. I want to clarify, I think Coldcard does many, many things right. I like them as a product. I recommend using them in their multisig. I think they’ve done great things for the industry. I think they’re very transparent in many ways. It’s not a slight on them. This applies to everyone. It’s not a specific issue to Coldcard. It’s a specific issue to single key signature schemes and relying 100 percent on something that you can’t verify.

# Air gap defense

SL: Let’s move on to other single signature single points of failure. We also have to guard against exfiltration. Periodically we see some of these attacks. Ledger Donjon will do an attack and show how we were able to exfiltrate the private key material from the device.

MF: Yeah. The biggest area you see this is in the air gap. This is why I really like QR code based air gaps. We’ll see this in the Cobo Vault which is a new product. Their air gap is spectacular. Plus it creates a great UX. But anytime you’re plugging a device physically into your computer it’s definitionally no longer air gapped. The whole point of an air gap is that you have a gap of air surrounding the device. A SD card is kind of like this middle area where it’s definitely better than USB cause the USB stack has so many more vulnerabilities. Imagine in the worst case the hardware wallet you bought was not genuine. You plug it into your computer, it’s actually a keyboard because it’s a USB drive that you plugged into the computer and it takes over your computer and starts installing malware from the internet. Now your computer actually is malware infected as is one of your hardware wallets. That’s a scary position that you could be in that’s avoidable if you don’t plug your hardware wallet into your computer. That’s just one example, one of many. A proper air gap means it is gapped by air. A SD card is a pretty good cheater that gets you most of the way there. We did see in the case of Stuxnet that the US government was able to jump the air gap into the Iranian nuclear reactor which is some crazy James Bond stuff. A SD card and a USB pen drive are not exactly the same thing but I wouldn’t want to rely a hundred percent on that air gap. Although it is definitely better than just keeping your seed on your software wallet.

# Differential power analysis attacks

SL: There’s also the secure element aspect. On some of the attacks they use these things like differential power analysis. Once you have the device physically you can extract the seed out from it. There have been attacks of this nature disclosed against say the Trezor wallets and others.

MF: These are almost considered like a side channel attack because the fundamental cryptography isn’t broken but there’s some side channel where you’re able to listen in. If you’re doing ECDSA signatures there’s a lot of like arithmetic happening and you could listen potentially to what that workload sounds like for the processor and determine from that pattern of noise what the key was. Realistically I think this is very very low concern. If you’re looking at [Glacier protocol](https://glacierprotocol.org/docs/overview/) they’re running noisemakers and stuff. I wouldn’t be too bothered by this. But again this is where multisig is different and each device would be different. Each device would need an attack specific to it. I do remember reading some standards once about computers that were on tables and how that sound traveled through the wood really far which was kind of terrifying because with a wooden table and wooden floor it could travel through the table to the floor. Again this is some extreme James Bond stuff. This is not what I worry about at all if I’m using multisig because I’m using different wallets by different vendors that are performing this stuff slightly differently. So just being tuned to listen would be pretty hard assuming it’s even possible. It’s theoretically possible but who knows if it’s practically possible. The bigger one that we see with the secure element is the physical security. The idea that you want to know that nobody could have broken into your safe and found your Coldcard and then pulled the seed off it. That is something that is definitionally different between the devices with secure elements and the devices without secure elements. In theory the ones with secure elements, even if you had physical possession of the device, you wouldn’t be able to extract the secret. Part of that is because the secure element will be encrypted and in order to decrypt it you need a key. Usually that’s on the secure element. In order to get that key you need to enter your PIN. The secure element will only allow so many PIN attempts. We kind of see this already. If you have an iPhone you can only enter your password so many times. You might have to wait some number of seconds between entries and then after some number of attempts it might get wiped. That is a very cool feature that is certainly in the single key signature setup if I were going to recommend one of those, I would want it. For multisig it gets a little bit different because now you’re talking about breaking into multiple secure locations which has such an enormous extra burden. You might want a PIN as well. But the default in multisig, it is already so secure that I would be a lot less concerned about having a secure element versus not. Part of that goes back to if you have a PIN you have to remember that PIN. That’s another thing you have to keep track of and you need a backup. Your backup is just going to be the seed phrase without your PIN. Now you’re back to the same problem. How can you have physical security on a piece of paper that’s written down with your seed phrase? If somebody gets access to that they’re going to see your seed phrase and you want to have a backup. This is another example where multisig just gets you to a different level where you can say “You need 3-of-5 of these.” That’s really hard to get. They’re going to be in safety deposit boxes and safes at home and buried in a mountain. Places that only the person who set it up knows. It is not impossible that somebody could steal three of those. But it’s so much harder that instead of worrying about PINs and secure elements we just worry about what are my 2-of-3 secure locations or my 3-of-5 secure locations. I can think about it that way. That offline security problem is something that we’re already pretty good at. We grasp intuitively and we understand whereas the cryptography part is very hard if you don’t have background in it.

# The Casa approach

Casa’s Wealth Security Protocol: https://docs.keys.casa/wealth-security-protocol/

SL: I’ve got two points here. I’d like to get your thoughts on here. In relation to physical security and trying to get that right, one level of additional protection you could have is use things like tamper evident bags that you’re periodically checking. You know if it’s been opened so that’s at least something. I guess the other point I would raise here is taking the Casa seedless line. The Casa approach on this would be something like “We’re using seedless and the reason for that is if you keep these backups, the 12 words or the 24 words, that itself can become another point of failure because if somebody gets that 24 words and you have no passphrase on that device then the attacker is getting one of your keys or one of your devices.

MF: An important nuance on what Casa does. I’m talking about their 3-of-5 offering. If you’re going to consider Casa you should 100 percent be in the 3-of-5 camp. But in their 3 of 5  you have one key that’s on a software wallet, that’s your phone, they hold a key and then you have three hardware wallet keys. The 3 hardware wallets by default do not have backup seeds. Casa backs up their key and the one key that’s on your phone you can back up. It has a feature for you to do that. It’s the hardware wallet ones they don’t back up because those are considered to already be designed around defending that. Although if you’re using a Trezor there is no physical security or no assumption of physical security. An attacker with a hundred dollars of equipment and physical access to that Trezor can pull the seed off of it. Whereas if they were using a Coldcard that would not be the case. That’s an important distinction with those. Back to Casa seedless, their hardware wallets by default they do them seedlessly because they believe that the risk that you’re going to mess it up is higher than the extra benefit of backups. I think this is a reasonable trade-off that reasonable people can disagree about. Most importantly, if you were to use that it’s your choice. Their recommendation is to do it that way. Their instructions are to do it that way but you set up your hardware wallet and you can back up that seed or not as you see fit.

# Malicious deposit addresses

SL: That contrasts with the Unchained Capital model where you are keeping the backup seeds and it’s a 2-of-3 with backups. In the do it yourself model it’s similar, you’ve got to make that call on exactly how you’re going to do that. Going back to some of the other potential single points of failure with single signature we’ve got this one around malicious deposit addresses. What’s the problem with this and how do we mitigate that?

MF: These are sort of the two oldest tricks in the book. The first one we talked about is the fake seed and that’s the one where we could see billion dollar retirement attacks from every single hardware wallet manufacturer out there. This would be possible which is so scary. The malicious deposit address, we’ve seen different versions of this for years. Early QR code generators for the blockchain.info’s of the world and coinbase.com of the world, people realized “I want my QR code generator to show my address and not your address” which is a really, really clever hack. Of course these sites are all well aware of this and they write their own software to generate their own QR codes. They don’t rely on a third party to render those QR codes. But it’s a great attack because at that moment somebody is looking at using that address for a deposit. So that’s when you’d want to substitute yours. You really want to make sure that your deposit address is yours. You really need to do that on more than one device because it would be so easy for a malicious device to substitute the attacker’s address for yours. And if you’re going to verify on two devices again we’re back to the multisig land where multisig is perfect for this. You can have two devices by two different vendors that are part of the same 2-of-3 quorum. You can get that level of security without having to do one device extra perfectly and put that seed on two different devices and check everything. That’s another example of where multisig just gives you this for free.

SL: I guess the guidance around that is making sure that you can check the address on your device. Depending on the device and the software you’re using there are varying levels of support for this?

MF: This is something we’ll get to later because in the multisig scheme it’s more complicated and there have been a lot of advances here which is really great. The other common single sig worry is about change in your spend. We think of I’m going to send you 10 dollars. In Bitcoin we’re dealing with UTXOs and I may spend a UTXO with 2 Bitcoin with 1 going to you and 1 is change back to me. Making sure that that 1 is change back to me and not change back to my attacker is really important. This can be very asymmetric because if I have a 1 Bitcoin UTXO that I need to spend, it’s my only UTXO, and I want to send you 0.1 Bitcoin, the change is going to be 0.9 Bitcoin. So the change can be 10 times larger than the spend. I need to be sure that that change really does belong to me. I could do this using multiple hardware wallets or checking my transaction with my private key in multiple places. But this is what multisig just does so well. We would get this for free if we were to check on two devices. Then the last one, which is the hardest one I think, is the randomness in the signature. The way ECDSA works is you prove that you have had possession of the private key and the private key is just this number between 1 and 2^256. In order to give that proof you use what’s called a nonce or a number used only once. You perform a cryptographic trick where you do something that is only possible if you had the private key and the nonce. The thing about it is if anyone else has the nonce and they have the signature then it’s trivial to get the private key. You need to know that this nonce is truly random. Now we’re back to this problem of proving random which practically speaking is very, very hard to do. You could get a hardware wallet, this is called a chosen nonce attack, that inserts the attacker’s nonce. You wouldn’t be able to tell until the transaction was broadcast and then they could potentially get that key. Now there’s a whole lot of asterisk in all of this. You would get the key for that signature only. That doesn’t mean you would get all the other keys for that wallet unless you had their extended public key. Some wallets by default like Trezor and Ledger do send extended public keys out to remote servers when you boot them up by default. Advanced users can find a way around it but by default that’s what happens with those wallets. That is scary.

SL: Small correction there. I think with Ledger they don’t actually send the xpub. I think they just direct query the next 100 addresses. But I believe that’s correct for Trezor.

MF: Thank you. Sorry. I don’t want to misstate anything on that. I could be not up to date on that. I haven’t tested the Ledger thoroughly in a while. But this chosen nonce attack, it is terrifying but probably narrow. And again almost completely solved using multisig because if you’re signing on two different devices by two different manufacturers your attacker would have to compromise the random number generator usage on the nonce for both of those devices. And then that still only by default gets you the key for that transaction which was validly signed. Maybe it’s just going to get mined. If there was no address reuse then that key wouldn’t be protecting anything else. So maybe this attack could exist in the wild and it would not be a problem but there’s so many ifs there and it’s so squirrely. If anyone has that xpub and that child private key then they are going to get all of your active private keys.Then it’s that it’s horrifically bad. Again multisig would just protect you from this. Proper multisig with multiple vendors and you don’t have to worry about this.

# Hardened and unhardened derivation

SL: That’s scary. For clarity there, part of the reason for that comes down to hardened derivation versus unhardened derivation. My understanding here is Bitcoin Core uses hardened derivation but pretty much every other wallet in the space for usability reasons uses unhardened derivation. That’s what gives rise to the possibility of that.

MF: What you said is technically correct. When you have a hardened derivation on the child path and then if somebody were to get that child private key and they had the xpub of the parent, they would not be able to get any of the parent’s private keys. You do get that level of protection. But the way Bitcoin Core does this versus the way wallets implement it has to do with the derivation for change branches and receiving address branches. You sort of have two functions in your wallet. You have addresses that you’re receiving from and you have addresses that are just change for your spends. It is a question of how you do the hardened derivation for those two things. You might want to just have a receive branch where you put a public key on a web server that’s kind of insecure and so that xpub could get leaked. You want that extra level of hardening. But fundamentally if you have a child xpub for say a bunch of receiving addresses and then a child private key is reversed through a chosen nonce attack, then all the children there of that child xpub and that child private key when combined would give you the rest of the child private keys for that branch. So there is a distinction on where the hardening took place but it’s way deep in the weeds. The point is that you don’t want to say “It’s just my change or just my receiving that’s at risk.” You just want none of these things to be at risk.

# Inheritance scenarios

SL: In practice many of the wallets are not using hardened derivation. That’s for a usability reason. So we have to try to protect against that chosen nonce attack. I guess the other big one here is inheritance. This is can be a bit difficult because many people in the space act as though we’re going to live forever when obviously that’s not true. We have to think about what people are going to do when they pass it on to their children or their family or whoever. How are you thinking about the inheritance scenario in single signature versus multi signature?

MF: Inheritance is one of the ones that I think Bitcoiners have the biggest blind spot to. Whenever someone tells me their Bitcoin is super secure I say “What happens if you get hit by a bus?” Nine times out of 10 they’re like “I guess I’d be dead so that’ll be okay.” But in single sig it’s really hard because you either have to give your private key material to somebody while you’re alive and trust that they won’t spend it or lose it or be hacked. Or you have to do some complicated scheme where you’re like “There’s a safety deposit box that I have now but it’s going to be yours.” Now I’m worried that the banker is going to look in the safety deposit box. Maybe that safety deposit box only has the seed phrase but then the passphrase is somewhere else. Or I’m going to give that to you or I’m going to use one of these dead man switches. It is not impossible but it’s not trivial because you have to pass everything to somebody when you die and you want them to have none of it while you’re alive. In multisig you can have a much more blended approach because you can say “I’m 3-of-5. I’m going to give one to heir A and 1 to heir B or a member of my estate A and a member of my estate B. Those are going to have two of my five keys and then I’m going to have three of them. One of my keys would be say in a safety deposit box or with a trusted third party.” It could be Unchained or Casa. It could be with a lawyer or accountant. The idea is there’s sort of a natural flow there. Maybe there is some room depending on the situation for collusion while you’re alive. But again this is your heirs colluding to get their inheritance. They’re probably the people that you want to have the money. So it’s a natural, smoother progression and it just works really well. It is sort of the biggest one. If you care about what happens to you when you get hit by a bus then multisig inheritance is great. I think it’s something a lot of Bitcoiners should care about. You can almost think about it as a free life insurance policy. If your Bitcoin dies with you then if you were able to find a way to make it pass along you can kind of put a price on what that would be worth. If you have a million dollars in Bitcoin you know what a million dollar life insurance policy would cost you. You can set it up by making sure your Bitcoin isn’t lost when you get hit by a bus. There’s real value to be captured there and I think that’s one of the biggest opportunities for the multisig service providers like Unchained and Casa because this is such a valuable thing.

# Security vs deterrence

SL: For sure. Now we’ve got to think about security vs deterrence. How should we think about that when we’re thinking about securing our keys?

MF: Security is an endless rabbit hole you can go down. Nothing is a 100 percent secure. Security is not binary. There’s always going to be a “Yeah but” or “I have this thing” or “I prefer that”. The way I want to try to phrase it is you can think of security as like a garage with a tall electrified fence. It is topped with razor wire, there’s an alarm and surveillance system. There’s automated flame throwers. It’s surrounded by a moat of alligators and you’re defending a Honda Civic. That car is not going to get touched. There’s giant signs everywhere. Deterrence is parking that same car on the street and putting the club on the steering wheel. Deterrence is rob the guy next to me and that’s probably what’s going to happen because the car next to you isn’t going to have the club and so your attacker is going to move on to that car. But if your car was a Bugatti or some really fancy high end car the club is not going to really do anything. That’s what a lot of these defenses are. They’re weak guarantees and they don’t reduce theft in aggregate. They just shift the robberies onto less suspecting victims, which to be fair are the ones that weren’t willing to do as much work to prevent it from happening. So maybe they didn’t care as much. But multisig makes attacks impractical and so we can reduce the aggregate number of attacks which is the really cool part. If you knew it was going to be this hard to steal someone’s Bitcoin because they do all of this stuff you might even try less and that’s pretty cool.

SL: Yeah I like that idea. It’s sort of like a herd immunity idea or a meta point. If it’s commonly used and a lot of people use multisig then it makes it a lot more difficult then because the attackers are now going to have to think “I’m going to have to compromise two places or three places to get it.”

MF: You should really think about this in the context of what a company’s position is on multisig. If they make great multisig products what they’re telling you is “We know we can’t be 100 percent secure, nothing is. We want to do everything we can to make your Bitcoin as secure as possible. We’ll work with other hardware wallets and other software so that we can give you this additive or even multiplicative security.” If instead a hardware wallet manufacturer says “Well yeah but we have feature X, Y or Z” and every hardware wallet has feature X, Y, or Z so we don’t need it. You should be incredibly skeptical of that pitch because all hardware wallets, remember we started out, have the ability to have not been using the random number generation software as they were supposed to be. They could be doing that attack right now. They could have been doing that attack for years and they’re just waiting for enough billions of dollars of value to accrue before they walk away with the money. They can talk about their advanced features. It’s all trust. It’s not verification and multisig fundamentally changes the equation.

# Progress in the ecosystem over the last year

SL: It becomes about the ecosystem and how the whole overall space is going. We’ve had some developments in that. So my next question to you would be how in your view has the hardware wallet and multisig space evolved since [SLP97](https://diyhpl.us/wiki/transcripts/stephan-livera-podcast/2019-08-08-michael-flaxman/) in August 2019?

MF: This is one of the things I’m most excited about. We’ve just seen a tonne of improvements in software, hardware and the hosted services as well although I don’t explicitly endorse them. I do think they have some room for improvement still to go. Let’s start with the software. The really exciting one is [Specter desktop](https://github.com/cryptoadvance/specter-desktop). You’ve done a great [interview](https://stephanlivera.com/episode/205/) with Stepan and Ben. I’m sorry I don’t remember the episode number but that one was really good.

SL: 205 I think.

MF: Specter desktop has great features. It is basically designed to be used which I think is the biggest thing that sets it aside from the others. It’s really simple. It’s designed so that you don’t shoot yourself in the foot and it’s all designed around keys, a quorum of keys going into a wallet. Then that wallet generating addresses and signing transactions. I’s pretty straightforward that you can attach hardware wallets to it. You can do something like Seedpicker which we’ll get to where you generate your own seed yourself. You put that in as part of your quorum. It has a one click binary. It’s compatible with other standards. It runs off Bitcoin core. Even I submitted a [pull request](https://github.com/cryptoadvance/specter-desktop/pull/334) to it that got merged a couple of weeks ago that adds Merkle proofs. This is a really cool one for future use. It’s not really designed to be used this way just yet but in the future you could have a friend or family member who runs a Bitcoin Core node who’s able to see your privacy information. But you wouldn’t have to run your own Bitcoin Core. You could trust them for consensus rules. That would make your setup much easier. Obviously that comes with risk. You should run your own Bitcoin Core but as a simpler one you can use Merkle proofs in Specter that way. Electrum has also made a lot of improvements but I would describe Electrum as less painful to use than it was before. I would only recommend it for expert users. It’s really challenging. There’s so many gotchas. I think the expression that comes to mind as a popular one in cryptography, you don’t want your cryptography to feel like juggling chainsaws while blindfolded and that’s what Electrum can feel like. There are steps that are not so easy to use. I guess we’ll get to that later. Specter desktop is the product that was built for this. It really is great. I became an open source contributor to it because I like it so much.

SL: That’s awesome. We’ve also got Caravan as well by Unchained Capital.

MF: Yes. This has come a long way. This time last year I believe it only supported pubkeys. You could put in a bunch of pubkeys and generate a single address. Now Caravan supports whole wallets. You can put in extended public keys and it will generate you addresses deterministically. It works out the gate with [blockstream.info](https://blockstream.info/) as their backend which obviously has privacy and consensus rule implications. But you can get started that easily or you can power it with your own full node which is what you should do. That’s pretty neat. It doesn’t support the good multisig hardware wallets yet although they have pledged to add Coldcard and I know they’re looking at Cobo Vault. It’s the best way to use the old gen hardware wallets for multisig. We’ll talk more about the newer better hardware wallets that are out there for multisig. Then [Sparrow](https://github.com/sparrowwallet/sparrow) is a brand new piece of software. It’s only a couple of weeks old and so I haven’t tested enough to endorse it and I have found a number of bugs. But it’s really cool to be able to export your Specter file and just import it into Sparrow right away and see your addresses and verify that way. So that’s exciting.

SL: How about hardware wallets?

# Cobo Vault

MF: The really big news in this is Cobo Vault. Cobo is new to the Bitcoin scene at least. They’ve been an altcoin wallet which I didn’t think very highly of because I’m no fan of s\*\*\*coins. But they do have a really spectacular air gap and Bitcoin only firmware now. If you’re doing any of this Bitcoin multisig stuff you have to use that firmware. That is obviously not a full solution. That’s problematic. But anyway back to the air gap. Their air gap is spectacular. They have a big screen and a camera. You can set the whole thing up without ever plugging it into a computer. You can verify receive addresses that way and you can sign transactions that way and broadcast the transactions back to your computer using a QR code. So just absolutely pristine best in class air gap. The UX on that is really good. There are some very real negatives. They are built on top of Android’s operating system. They do harden it but that’s closer to a general purpose computer. That’s not what we like to see for guarding private keys. They have open sourced a lot of what they’re doing but not everything. It leaves a lot of room because you only care about these very specific things like seed and address generation. I don’t really care if the menu buttons are open sourced. That is always of concern but their constraint is that they use a secure element and all the secure elements are closed source and under NDA. So you can’t open source all of your code. They’re doing well within that constraint and that’s what’s allowed them to build this great product but it does have this big asterisk. I’m trying to think of the other Cobo tradeoffs but really I’ve just been impressed. The biggest thing is they ship. They contacted me after the last episode and said they wanted to add all the things that I was saying that I wanted to see in a BIP174, PSBT supporting hardware wallet. They put out milestones for when they were going to do it for single key, for multisig, for adding testnet and a bunch of other stuff. They’ve just chipped away at adding these features. I love to see that. I think having two that are good at multisig, Coldcard being the obvious one, they invented BIP174 and they’ve been around for a bit longer, is really a game changer because now everyone has to get on board. They’re your two in your 2-of-3 and everyone else is now in the position of can they be added to that or not? It’s no longer this question of obscure feature X, Y, or Z. It is is it possible to use you in a secure multisig? Right now for most but not quite all of the other hardware wallets the answer is no. That’s something that I think is really going to change because we have a standard and everything is using it. We’re going to see more and more support. 

# Seedpicker

https://github.com/merland/seedpicker

MF: The next hardware wallet that I’m excited about is not a hardware wallet, it’s a software wallet. It was also somewhat in response to our last episode SLP97, it’s called Seedpicker. It’s at [seedpicker.net](https://seedpicker.net/calculator/last-word.html). It is a cool one because I was just messaging with this guy Merland, I’m embarrassed, I don’t even know his name in real life. He agreed to make it into a Specter desktop multisig tool and that’s what he’s done. He’s continued to iterate on it constantly and pushes updates all the time. I think it’s getting pretty close to its terminal state just because it’s really good. But the basic idea is it’s a lot like [bitaddress.org](https://www.bitaddress.org/) if your listeners remember that from five years ago. It is a site that I do not recommend but it’s to generate a paper wallet. You would go to this website and move your mouse or bang on your keyboard for randomness. It would give you a private key and an address in a bunch of different formats and with QR codes and you’d print it out. You could use that for receiving Bitcoin. Of course there’s address reuse issues when you want to go spend your Bitcoin. It’s really problematic because at that moment you have to load your WIF, your Wallet Import Format private key onto some software that you probably should have had tested and set up really secure before you started receiving Bitcoin. That notoriously caused problems for people if that software tried to sweep it before it was part of that new wallet and then their funds were in some weird place. I know I had people come to me where their transactions stalled out in that moment and they were just so confused as their funds were between wallets. Seedpicker is like that but without any of the negatives. You are the randomness, you pull 23 words out of a hat. It also has a guide if you want to use raffle tickets or other ways to do it so that you don’t have to print out 2000 words and draw them out of a hat. You put in those 23 words and it appends for you automatically the 24th word, the checksum. Then it gives you the public key info that Specter desktop needs to coordinate your multisig. That’s the [SLIP 132](https://github.com/satoshilabs/slips/blob/master/slip-0132.md) version byte formatting, your root fingerprint for your wallet and the derivation path. All that stuff is stuff you don’t really need to know or understand. You just hand it to Specter and you’re good to go. But you have to be obviously concerned that this tool could be lying to you in the same way that I was saying before the hardware wallets could. Maybe the extended public key information that it’s giving to Specter Desktop doesn’t correspond to the seed that you pulled out of a hat. It could be just totally faking you. You want to confirm that on a separate setup. One of the things that I did to make this easier is I published some free open source software called [human-rng](https://github.com/mflaxman/human-rng-electrum) or human random number generator. The joke being you are the random number generator. I wrote this in both Python and Golang, just for extra redundancy. You could type in that same seed into that library and confirm “Do I get the same checksum and do I get the same public key information?” If you’ve got it in JavaScript, Python and Golang I would feel real confident that was good. But if you don’t trust it write another implementation in other language, run it against that, that would be great. Of course all of this should be done offline on an air gapped machine, never touched the internet, wipe it afterwards. I don’t want to see any of your information. To be fair the Seedpicker one has a nice GUI and anyone could go ahead and use that. If you could use bitaddress.org you can figure out seedpicker.net. My stuff is command line only because that’s all I wrote for now. I would like to put a GUI on it one day, just busy.

# Other hardware wallets

SL: Lots of things to do. How about some of the other hardware wallets?

MF: Coldcard has fixed a bunch of bugs. There was a huge one having to do with extended public key ordering that was this mystery bug that persisted for 11 months where sometimes the Coldcard just couldn’t verify receive addresses on the screen. That got merged about a month ago. The Trezor recently added support for stateless address verification. That came through your sponsor Unchained. Their CTO Dhruv submitted a pull request that added this functionality, I would say badly missing functionality, to the Trezor. You can now with a Trezor prove that this Trezor is part of this quorum. If you have a 2-of-3 and you have a Trezor, you want to know “Is my Trezor even included in this address? Yes I’m one of the 2-of-3.” Now there is an obvious negative here. You’re only one of the 2-of-3, the other two could be your attacker. So you need to verify that’s not the case and Cobo and Coldcard have some built in defenses against that. Trezor is stateless so it doesn’t store the information of your other co-signers. That’s a huge vulnerability for using Trezor for multisig but still it’s a big improvement from where they were before. Then Ledger has strangely come out kind of against multisig in a bizarre turn of events. I want to address that a little bit. On [SLP103](https://stephanlivera.com/episode/103/) shortly after our last interview Charles Guillemet, their chief information security officer, said and I quote “a tiny mistake can lead to massive loss at scale and this is very concerning to me.” I thought this was a really bizarre thing for a security company to say. This was his response to a question about multisig. They don’t really support multisig. They can’t verify a receive address in any way. On spends they can’t tell what change is, which makes sending very hard for anybody but an expert user to verify. It is sort of a bizarre one. The only thing that I can think is that they offer this competing single sig product that works between other closed source Ledger devices. So you could have a quorum of Ledger devices use cryptography that’s totally outside Bitcoin or the blockchain to validate that m of these devices have agreed. Then they’ll sign a transaction that they broadcast on chain. That would support hundreds of s\*\*\*coins. Those coins may not support onchain multisig. That’s my guess at what Ledger is getting at. It was very weird. I even called out one of the quotes from your episode and tweeted it out. They said that they wouldn’t respond to solipsism, I wasn’t sure what that meant but they said they wouldn’t respond to it. I think these are the exact types of things they should be doing. The other wallets are moving in this direction. The additive power of multisig is really cool that even if a wallet say like Ledger is closed source I don’t have a problem with that.  That could provide additive security in a multisig environment. I think their stance is very bizarre and sort of uncharacteristic in the rest of the industry. I hope that they will reconsider adding support for multisig in the future.

# Hosted services

SL: For sure. And also thoughts on the hosted services?

MF: They’ve gotten much better too. So the big one is address verification. I didn’t want to talk about these services publicly because I love multisig so much but they didn’t have much in the way of address verification in the past and now they do. That’s gotten a lot better. Unchained can verify and you can verify an address on your device with just a Trezor. With Casa they support Coldcard as well. Coldcard is sort of like the gold standard or at least the innovator for multisig. They invented [BIP174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) and they were sort of the first to do it well. So Casa has the big advantage that you can use both Trezor and Coldcard and you really should be doing multi vendor multisig. Because again the scariest attack would be that you buy two of one device and the random number generator on that wasn’t being used correctly. Then two of your three seeds have been compromised just because you bought two devices. Maybe you’ve got them from the provider, maybe they sent them to you so there’s just so much room for tampering there. Casa does support both Coldcard and, Trezor, neither of these guys support Cobo. I know they’re both looking into it and we’ll see when we get through again into this guide about some of the advanced features Cobo has and why you really want to have that as part of your quorum. There are negatives with Cobo, I don’t want to say that it’s a perfect device. But for multisig compared to what’s out there it’s sort of a must have for your quorum.

MF: The hosted services have gotten much better at sovereign recovery. So Unchained has the slick [Caravan](https://github.com/unchained-capital/caravan) tool and they have a [video](https://www.youtube.com/watch?v=WyIKuReOVd0&list=PLUM8mrUjWoPRsVGEZ1gTntqPd4xrQZoiH&index=4) on their website and you can see that if we went out of business or we were malicious this is how you get your funds unstuck with your two hardware wallets. It is as easy as you can make this. Then Casa will show you how to do it with Electrum. That’s really hard. I would say that’s expert only level stuff but you can do it. Obviously it’s not a normal use case. Casa makes money every month that you pay them so they’re not looking to go out of business or anything. I think that’s okay. If some crazy event happened and you had to pull out of Casa on your own and they were no longer responsive they do have the sovereign recovery [instructions](https://walletsrecovery.org/recovery-docs/casa-recovery.html) that are just difficult because of Electrum constraints. But they’re doable. If you had to figure it out you could probably figure it out. Those are my asterisk. I think those services are about to be so good, especially when you layer in inheritance but I think they’re just still not quite where I’d want them to be yet.

SL: Another small correction with BIP174, I believe that was actually written by Andrew Chow. To your point I think it’s that Coldcard were the first to support it in terms of hardware wallets.Their wallet is natively PSBT. I guess that’s the point we’re getting out there.

MF: Yes sorry about that.

SL: No that’s fine. Just wanted to make sure Andrew Chow got his shout out because he did make it. and with.

MF: And it is Andrew Chow’s HWI that powers Specter desktop which allows for all this multisig stuff to be accessible to the masses. So maybe a silent hero not getting credit.

# Complexity of multisig setups

SL: He puts in a lot of work to keep that going. I guess the main counterargument when I talk to someone like Rodolfo (Novak) CEO of Coldcard, the creator of Coldcard, he might say “Multisig is great but a lot of people shoot themselves in the foot because there’s a lot of complexity with this. What are your views on the complexity of multisig and whether it is worth it?

MF: I remember once Bryan Bishop, a Bitcoin core developer, said this at a Austin Bitcoin developer meetup. I don’t know whether it was his originally or whether this is somebody else that he took this from. But he said that multisig doesn’t add any complexity, it just forces you to perform the steps upfront. I think that’s really spot on. You should be verifying your seed when you generate it on two different devices and single sig users notoriously do not do this. It’s got to be single digit percent at best. If you’re doing single sig correctly you should be verifying that twice. You could just have two hardware wallets and create a seed twice that way and be much more careless about your level of caution at each step. Whether it’s updating your firmware or are you going to roll dice or use Seedpicker or just trust the thing because you bought it from them at a conference and they seem reputable. I would say the main point that he’s making was true historically but it’s just not true anymore. Multisig used to be really, really hard. When it was Electrum only, when we didn’t have Cobo and when Coldcard’s integration with Electrum was not so nicely done. Electrum for almost a year did not release a new binary. You had to build this stuff from source, from the command line. All of this stuff used to be hard and I think all of his complaints were very fair then. I wouldn’t say that it’s easy now. I would say it’s intermediate now but it’s getting easier. Also in Rodolfo’s case, he’s running a business and he’s dealing with the consequences of customer mistakes all the time. While they’ve done some really good things like implementing PSBT, they’re a business, they have to focus on the present and not so much where the future growth is. The future growth is going to be in multisig. They’re doing a great job at that too so they’re going to sell devices. I’m not saying that they’re built on the past but they’re just focused on responding to the issues they’ve had in the last six months. In the last six months people trying multisig have run into issues. A lot of those are just way better now. If you were trying to do it on Electrum and you now try it on Specter Desktop, it’s a different game. If you were trying to do this on a Ledger and instead you try now to do it on a Cobo Vault it’s day and night. I think try again and revisit that statement as time passes. But we’ve reached this inflection point now because everyone’s sort of using a standard. Everything has to be coordinated across multiple devices and multiple software and so we’ve ossified on a standard for the most part. There might be changes to it but they won’t be backwards incompatible. For that reason everyone used to be really afraid about building something that wasn’t going to be the way that other people would do it. When hardware wallets would come to me and say “We want to do more multisig support but we want to just work with whatever is going to be the thing that everyone uses.” Now that equation has changed. Now there is a thing that you can do a 2-of-3 with Cobo and Coldcard and a free open source software wallet. That’s great. If you want to layer on a Trezor you can, although there are some hesitations. I would say that’s for expert users. There will only be more that want to be a part of that scheme and that want to improve how they perform in that scheme. I think this is so exciting. I could not be more thrilled.

SL: I would summarize it as we’ve got a big increase and improvement in the UX, the user experience, and we are seeing some formation of a kind of standard in terms of how the wallets work. They’re using PSBT and the backup is with Specter desktop. You’ve got that JSON file, JavaScript Object Notation file. We’re sort of firming up around some sense of a standard and perhaps over the years it will become more and more commonplace.

MF: Yes exactly. Back to this idea that it should be super simple. No Bitcoin transaction, single key sig or multisig is ever going to be that straightforward. Bitcoin is a financial weapon. You should treat it like owning a gun. If you’re going to self custody you should educate yourself on safety. You should reeducate yourself and you should practise. Bitcoin is the insurance policy that money can’t buy but you need to know how to make good on that policy. No one’s going to do that for you. It has gotten a lot easier and it’s getting better all the time. It’s going to get even better. But it’s never going to be as simple as sending a tweet and that’s ok.

# Single signature and passphrase

SL: Before we get into the guide in a bit more detail we’ve got the last point I wanted to cover. Let’s say you just use Coldcard, single signature and you use a long, say 6 or 7 word passphrase. Why should we still use multisig instead of that single signature set up?

MF: You’re solving a specific class of attack which is the random number generator on seed generation. Imagine that your seed phrase was compromised but you have the 6 word passphrase and that’s a long passphrase. Now you have to remember and store that. That becomes a new bit of complexity. In the multisig scheme that we’re going to go over I do not recommend passphrases except for expert users. If somebody has to break into 3 of 5 secure locations that’s going to be really hard to pull off. Only once you think that’s a realistic concern for your threat model, because you’re storing a hundred million dollars in Bitcoin, then you start worrying about passphrases. But for most people passphrases are not going to be a consideration in a multisig scheme. In single sig you would need to have a passphrase or it’s a very good practice, we’ll say it that way. Assuming it’s the full 6 words so that it’s too long to brute force and then you test that passphrase and seed combo on another device. Because remember the easiest attack in the book is to just let you enter a 24 word seed and a really long passphrase and ignore the whole thing. Just show your attacker’s deposit address and not even use it in the first place. You need to verify that on another device. If you did all of that then you would solve all of the problems that had to do with the seed and receive addresses. But remember that’s only part of the points of failure. You will have to recheck every time you do a deposit address on multiple devices. You have to be sure that your change is going to you and not your attacker. Remember that case of I send you 0.1 Bitcoin and 0.9 back to me but 0.9 goes to the attacker. Then we still have to worry about the chosen nonce attack or the randomness on signing, the k value in your ECDSA signature. What you described for experts I think is good, but it’s very, very hard. I would say for an expert looking to store a small amount I would say that makes sense. But for somebody who isn’t an expert, just use a multisig product, do proper multisig which is effectively 2-of-3 or 3-of-5 using multiple vendors where no vendor controls the quorum of your keys. If you do that it becomes hard to mess up. Practically speaking there’s a little bit of glue. You’ve got to run Bitcoin Core and install this software and have these devices. It is not easy but if you’re tech savvy and you understand how these parts work you don’t need to write code, you don’t need to be worried about what does this mean and if I make one mistake I’m going to lose all my money.

# 10x Security Bitcoin Guide target user

https://btcguide.github.io/

SL: Let’s get into the guide. You’ve written this guide, I’ve given a little bit of feedback here and there. It’s called the 10x Security Bitcoin Guide. Let’s start with who is the target user for this?

MF: You understand the key concepts in Bitcoin, you get the idea that there’s public keys and private keys, that you sign transactions, that there’s this database of ownership called a blockchain, that you run a node to validate that database and keep a copy. You kind of have to understand what the parts are. You’re tech savvy but you don’t write code. There’s no command line. But you are comfortable with software that I would say is somewhat in beta. It’s weird to have beta software and say “This is really good for a hundred million dollars.” The reason is because the security of your Bitcoin is enforced by the Bitcoin scripting language. You’re getting the security of the Bitcoin network as far as making sure that those 2-of-3 or 3-of-5 signatures took place. The beta software is going to be a confusing dialogue box, a button that’s in the wrong place, copy that doesn’t totally make sense, a difficulty running it on this operating system or that operating system, a cross compatibility issue. It’s a weird thing to say “It’s beta but it’s totally more secure.” Hopefully people will internalize or understand that concept. But you have to be comfortable with beta software. The idea that there could be some weird workaround or awkward thing here or there. You take security seriously. If you don’t care about security single key is better for you. You’re happy with the price point because if you want to buy the two hardware wallets which is the absolute minimum, a Cobo and a Coldcard, I think you’re at like over 200 dollars already. Then you do need a computer but you can use your main computer. You don’t need a dedicated machine for this. At each step there are more advanced things you can do. There are ways to harden your security and a dedicated machine is one of those. But the beauty of this massive multisig is that you don’t need to go to the nth degree because you have the security of multisig already which is far, far more secure. So I call it the 10x security Bitcoin guide. I think in practice most people who will use this are only going to get 3 to 5x greater security than their current setup, the 10x requires things like a dedicated device. There’s a lot of different steps for hardening but a 3 to 5x improvement is still fantastic. It really becomes hard to ascribe a dollar value to when you should upgrade your security. Some people go full tinfoil hat to secure a hundred dollars and others put 10 million dollars on an Opendime. So I can’t tell you this is the amount for you. A lot of people put a hundred thousand dollars into Bitcoin. They’re 100 percent in Bitcoin, it’s all of their money, it’s their life savings, it would be catastrophically bad if something happens to them. Some people write hundred thousand dollar bets and couldn’t care less. If it got hacked it wouldn’t even be a big deal to them. I can’t even tell you how to think about that. I can only tell you if you’re uncomfortable about it this is the thing that works. The security here is so much better than a single key setup.

SL: So this isn’t for grandma but it is for let’s call it the tech savvy user. I think many of my listeners would fall into that camp.

MF: Multisig won’t prevent you from entering your seed phrase into a web wallet. If you don’t understand the basics multisig won’t catch you there. The one asterisk I would say on that is that you’d have to enter a quorum of your seed phrases into a quorum of web wallets. You’d have to do it multiple times. But if you were tricked to do it once you’d probably be tricked into doing it multiple times. Although I will say that I just have so many horror stories of people messing up their Bitcoin who know better. I think I remember once late at night, the circumstances aren’t that important, I accidentally typed my private key into the search bar of a block explorer which is just the dumbest thing that you could do. Fortunately it was a block explorer that I wrote so I felt very confident that it wasn’t doing anything malicious with it. I still had to sweep the funds immediately. But I was playing around with a block explorer adding functionality to support xpubs so you could track a collection of addresses. I was also doing some private key management stuff and I shouldn’t have been doing those two things at the same time. As I was testing search I copy and pasted a private key into my own search bar. Maybe that’s a bad example beause I’m just telling my own stupid story but I know so many Bitcoin developers who’ve lost money in stupid ways. Multisig does prevent you from in the sense that you have to do something stupid more than once. That by the way would be a great way for somebody to monetize a block explorer. Block explorers don’t make any money so you could listen for seed phrases and stuff. I bet that happens like one in a million page views. If you’re looking to make the world worse there’s your opportunity.

# Third hardware wallet vs Seedpicker

SL: So the guide makes use of two hardware wallets, the recommended is Coldcard and a Cobo plus Seedpicker. I guess one question people might be thinking is why use Seedpicker instead of a third hardware wallet? Let’s say a Ledger or a Trezor or something else.

MF: You could use three hardware wallets. It’s definitely not a bad idea. There are some huge benefits to Seedpicker. First of all it’s free. You can’t beat the price that costs nothing. Telling somebody that to get started they have to buy three devices is just a bit much. Two is less to buy than three. It also is the only provable random number generator. It is the only one that’s designed around being provable. It’s sort of an end to end test. You put in the 23 words and everything else that comes out, the 24th word checksum, the extended public key information, that all is deterministic. You can do that many times. You can do it on many different softwares.You don’t even need for example the software to be open source. Seedpicker is and my complimentary library is called Human Random Number Generator, Human RNG, I have ones in both Python and Golang. Those are all open source as they should be. But strictly speaking this is a functional test. You’re going to input these 23 words and you’re going to get a 24th word and extended public key info. As long as you’re not connected to the internet and you’re not saving anything, you’re wiping the computer afterwards, you could do this in as many softwares as possible. Each time prove that “I got the same output. This is valid.” The only question mark is when I pulled these words out of a hat was I somehow biased? You can know that you didn’t do that. Also for a quick lesson in entropy, the 23 words is such a massive amount of entropy. One piece of feedback I’ve heard people say is that they’re afraid their 2048 word list wouldn’t be perfectly well shuffled. They’d cut up those words, put them in a hat but maybe they’re still a little alphabetical here and there. It’s just so much more entropy than you need that you really don’t need to be concerned about this at all. I know for example Stepan Snigirev of Specter desktop, he sometimes uses 12 word seeds for himself with a passphrase. Not exactly the same thing but if you do the calculations on how much entropy it is we’re talking about a mindbogglingly large number. You don’t have to stress about getting it perfect. Another step that you might not get perfect is technically speaking in the BIP 39 and BIP 44 spec, you should put each word back in the hat between times where you pull it out. You could pull the same word twice in your seed and to do it right you should do that. In practice it’s kind of easier to pull them all out and put them on the table one at a time and then have it that way. This is the type of thing where the beauty of these large numbers and these massive multisig is that you just don’t have to stress about it. If you don’t put the numbers back in the hat you’re not perfectly following the spec but that’s ok. That’s a good example of one of the many steps that gives advanced instructions in the guide. The default is just do it the easy way but if you want to be advanced you can put a word back each time and write it down instead and that’s okay too.

SL: The software is free but if you want to use it in the proper way, with a air gapped computer that you haven’t used for anything else and it’s never been on the internet you do have to pay for a cheap laptop to do that with?

MF: This is one of the many asterisk on the guide. This is a great use of a Raspberry Pi or some really old laptop you have laying around. The other thing you can do that is totally free is you can use your existing laptop and you can run this software and then you can wipe it.

SL: Like Tails?

MF: Or even better is to use Tails. Tails is an operating system called The Amnesic Incognito Live System or Tails. It’s designed to be used for the privacy paranoid but it’s mainstream. It has Tor and a password manager and some basic functionality. You could use it as your real computer if you were a privacy conscious type but it wipes itself every time you shut it down and wipes itself quite thoroughly. It wipes the RAM to prevent a cold boot attack and it’s free, open source, popular software. It also comes with Electrum pre-installed which is kind of neat. You could boot your computer using Tails totally disconnected from the internet. If you want to be paranoid take out the hard drive, take out the networking card but boot your computer with that. Calculate your 24th word and then boot it back into Windows or Mac or Linux, whatever you’re running, and go about using your computer knowing that there should be no remnant of it. If you want to be 100 percent sure obviously you need to have an eternally quarantined machine that you never reconnect to the internet. You encrypt the disc and you wipe it. But this is accessible enough and the point of this key is to be your recovery key. So it’s your one key that is only if something goes wrong with the other two. It would be a good one to put in a safety deposit box and say that that safety deposit box goes to your family if something happens to you. You can use that as part of your inheritance plan. It is not one that you actively use but if you need to it’s there. The real reason that we’re doing this is that 2-of-2 would be a terrible scheme. Let’s say you did a 2-of-2 and there was some problem with one of your hardware wallets. Perhaps it was generating an extended public key that didn’t correspond to your seed phrase. Your funds would be permanently locked up. By using a 2-of-3 where this is your third if something were to go wrong you have the ability to go into that safe or wherever and get that third key and use that with one of your other two hardware wallets. It’s a great backup. You can sleep at night that if something happens you’ll be okay.

# Specter vs Electrum vs Bitcoin Core

SL: We’ve done a lot of setup work. Talking through some of the context and why certain decisions were made. In terms of coordinator software maybe you just want to touch on why Specter and not say Electrum? Or perhaps being a wizard and using Bitcoin Core multisig and using the command line like a true hacker?

MF: Let’s start with Electrum. Electrum is that feeling of juggling chainsaws in the dark. There are UI gotchas everywhere. It is things like you’ll be on one page and the default radio checkbox at setup is checked. When you hit Next it says “Error. Invalid choice”. You’re like “Why did it trick me into that default check box that wasn’t usable?” It has a lot of these things like that. The order of the keys that you put them in matters I believe. If you ask anyone who’s very tech savvy and has used Electrum for multisig they will tell you that it technically worked but it did not go well. Specter is designed around not having these problems. Another one that’s really big is Electrum has limited BIP 39 support and deeply confusing messaging around this. When you try to import a BIP 39 wallet it warns you that they might drop support for BIP39 in the future which is a very bizarre statement. If Electrum ever dropped BIP39 support I imagine people would drop Electrum and switch to a fork of it that had BIP 39 support. Using Electrum you can’t create a BIP 39 wallet, when you want to import your BIP 39 wallet you paste it or you type in that phrase and there is no Next button because it’s not compatible with their input format. You have to find a hidden option BIP 39 checkbox. That is pretty bad because all hardware wallets use BIP 39 and it is the standard. They had another standard previously that didn’t get as much adoption. I think they’re just bitter that another standard is more popular and refuse to support it. There’s also UTXO privacy issues. The default way to use Electrum is to query third party services for your balance and transaction history. Those services we believe to mostly be run by Chainalysis companies that record share with the government. Now you don’t have to use Electrum that way, it’s recommended that you run your own Electrum server. I do like that you can get started with Electrum, for example offline usage, without having to connect to any node. The fact that the default use is so horrific is not necessarily bad. It is a choice that people can opt into. For a while the project almost seemed abandoned. They went almost a year without releasing an update. This has to do with a bizarre thing in the way they were doing their Git branches. They were operating with something called a dirty master branch which is basic software engineering. You never want to have a dirty master branch. They couldn’t push new code releases because they had this branch where they were trying to be a Lightning wallet. Their focus now, they support Lightning and that’s what they’re working on. Because they were trying to do that they couldn’t release any new updates. People were trying to use a Coldcard for multisig and they’ve got to build it from source for almost a year. I got so many messages of despair from people saying “Please I want to have multisig but Electrum doesn’t have a downloadable binary.” I was at the time even thinking of hosting my own binary and signing it which is inherently sketchy that people would trust that. But at least they would have something that they could use. Then Specter came along and just solved all the Electrum problems and more. It was a relief when I was able to upgrade to that. Then you asked why not just use Bitcoin Core multisig like a wizard? There’s a couple of reasons not to. One is you still need to guard your secrets somewhere and you don’t want that to be on a hot machine. So Specter is the bridge between the blockchain and your hardware wallets but your hardware wallets guard the secrets so they don’t leave the hardware wallet. Using the command line, it really does limit you to experts only. If you write code you might be more comfortable with the command line but that’s an insignificant percentage of users. Even experts shouldn’t use the command line because poor GUIs is how you make mistakes. When I gave that example of when I stupidly copy pasted my own private key into a block explorer it’s because I had a file open where I could do that and it would accept any input. You shouldn’t have a position which you could be in to make those kinds of mistakes. Specter actually does use the command line interface to interact with your Bitcoin Core. Everything that Specter does under the hood is making RPC calls to your Bitcoin Core and just organizing the data, displaying it. But it is effectively a way that you can be a wizard just by using Specter. Specter is the perfect balance of this. It just nails it. It’s purpose built for the task and it really does a good job. The only negative I would say with Specter is that you do have to run your own full node. Hopefully in the future it’ll be easier to rely on a friend or family member’s full node. That will come with privacy and consensus validation tradeoffs but for many people that might be worth it and that would make getting set up even easier. That’s why I submitted that pull request that uses these Merkle proofs so that you can validate your transaction was included in a block without having to even have that block. It is also cryptographically very cool. Merkle proofs operate in O(log n) space and time. They’re incredibly performant. That will scale forever and that was Satoshi’s cleverness in the original version of Bitcoin that he thought to put that in. Even though the Merkle proofs themselves didn’t come for much longer, he enabled the functionality from the beginning. That’s a really clever use. I’m just really proud to have done that. I’ve been taking some personal time. I hadn’t written much code in a couple of years. To write something like that and have it get merged into an open source project, that was pretty cool for me. I guess that’s Specter in a nutshell. It’s pretty neat and it’s got a one click downloadable binary. So if you haven’t used it yet check it out.

# Equipment needed for the 10x Security Guide

SL: Fantastic. We’ve done a lot of the setup stuff now. Let’s talk through the process. I think listeners can already appreciate we’ve already done a lot of the context. So now it’s kind of just pulling those right pieces together. So maybe you want to start with what equipment do we need to do the 10x security guide?

MF: The really big thing is you need these two hardware wallets and I’m recommending the Coldcard MK3 and the Cobo Vault. I do look forward to a day when there are like 10 great ones and you can pick your flavor of which one you want. Which one has the better air gap and the better open source and the one that’s more ideologically aligned with you or whatever it is. But right now I would say those are the only two that do multisig well. That’s the big expense. You need those two. You also need a laptop. Any low end computer would work but you need a webcam and laptops just work really, really well. If you have to pick them up and scan a QR code you can. If you need to take them into a safe, into a vault they already have batteries in them. A laptop would be good but it could be just a low end computer. The computer you already use is totally fine. You don’t need a dedicated machine although it would be better. Then you need some paper and pen to write down seed backups and you need either a pen drive or preferably DVD drive for passing around some public key information. But these are all pretty basic things. If you’re going to use Seedpicker you need the 2048 word wordlist. You need a printer that can print out two pages of totally nonsensitive public information. My hope is that in the future this will actually become like a little mini business model or party favor. Your local Bitcoin meetup could have a little stack of 2048 note cards. They don’t need to be full sized note cards, tiny little words for drawing out of a hat. Give that to people at the meetup. They could be sold on Amazon, they could be sold over the Lightning Network like stickers used to be sold. You could be selling a pack of 2000 words. But if not you just print out these two pages and get cutting with your scissors, pretty basic. Then you’ll also need a Bitcoin Vore node. My recommendation is that you should just use a product like myNode or a Nodl or Raspibiltz because setting up Bitcoin core is a whole thing. If you know how to do that then obviously you need whatever level of hardware you want for your own Bitcoin Core node. That could be a Raspberry Pi or you could want a really highly performant beefy machine, maybe you’re doing blockchain analysis too.

SL: I guess if you’re doing that setup you would have to do one small edit in the `bitcoin.conf` file. Otherwise if you’re just using say myNode, which actually already packages Specter then that makes it a bit easier as well. If you’re looking for an easy way to get into it.

MF: I didn’t know myNode is packaging Specter. That is awesome.

SL: The premium version has Specter packaged to it. So basically you could literally just open up your computer and on your internal network point to the Specter address and run it that way.

MF: That is really cool. Anything that makes it easier to get set up because one of the big points that’s so valuable here, and Specter is built around this, is that Specter can’t move any money. It doesn’t ever see a private key, it’s designed to be untrusted. That’s part of the reason why it’s called Specter. It’s a joke that everything can be hacked and so can this. You don’t have to worry about being extremely careful in this. You should still be worried because it could still try to trick you and maybe you would fall for it. But in practice you don’t have to have such level of paranoia or caution around your hot machine. You should be paranoid and cautious with your hardware wallets but that makes sense, people already are. So that’s really great that there’s a one click deploy. I did not know that.

# Initializing hardware wallets

SL: So that’d be another easy way for listeners to try this out. Now let’s talk about initializing and setting up hardware wallets. I can see straight off the bat the fact that you’re recommending the Cobo and the Coldcard there’s an advantage there because that’s arguably less privacy doxing than the Ledger or Trezor setups where you have to initialize the device and unless you are advanced it has to call home to their server. Whereas with Cobo and Coldcard you can actually initialize it offline with a wall plug and never computer connect it.

MF: One of the things that that reinforces is this design around PSBT or BIP174. Both of these wallets have first class support for partially signed Bitcoin transactions. The mechanism there is that they don’t plug into your computer by default and violate the air gap in order to interact. So when we talk about a Ledger or Trezor being connected to a central server we’re talking about it being connected to your computer via hard wire and then that somehow phoning home. In the case of Cobo and Coldcard that’s not how they’re designed to be used. So with the Cobo you can operate it never plugging it into your computer ever which is really cool. With the Coldcard that statement is mostly true with this asterisk that in order to verify a receive address you do need to plug it in. There’s an open issue for Coldcard for that. I really hope that they can do offline address exploration for multisig. They support it in single key sig so I hope they’re working on that. I hope it’s close. It’s sort of a complicated UX trade off but the idea is that these devices are designed to work without drivers, without installation, without phoning home. That’s really, really cool. They both do have validation mechanisms. The Cobo will give you some sort of proof that the device is legit which you can do all over the air gap. I forget the Coldcard one, I haven’t done it recently, but there is some level of proof. That is really cool. They’re just a different model because they were designed around a BIP 174 PSBT style from the beginning. Even though Coldcard was invented before PSBT they were thinking about it in this way that data should come in and it should be signed and the signed data be returned. Not this device should be connected to your computer all the time. BIP174, it’s just a serialization format for passing around the data. It’s not essential in and of itself except that it’s the standard that everyone should follow.

# Seedpicker initialization process

SL: We spoke about this before but just to talk through the Seedpicker initialization process. So as I understand you have that paper print out or maybe you’ve bought it from someone or maybe online people will sell those pieces of paper. You’d cut it all up and put it in the hat and draw out the 23 words. On let’s say your Tails laptop or your eternally quarantined laptop you put in those 23 words and get it to give you the checksum 24th word. That becomes your third key in the set up.

MF: Exactly. You write down those 24 words, for regular users just on a piece of paper, for advanced users etch into metal. Seedpicker is going to give you this file that has the public key info for Specter desktop. That’s your SLIP 132 formatted extended public key which is going to be in zpub format, your root fingerprint and your derivation path. None of that do you really need to know anything about. It just gives you a file and you give it back to Seedpicker. Now you should validate all of it. So if you’re an advanced user, if you’re storing a lot, you should run those same steps with another software package. I publish open source ones in two languages, Python and Golang. I hope there will be many others. You could put in those seed words and make sure that you get the same extended public key information. The basic point is that you just write down all 24 words and then you take the public key info back to Specter. Either on a DVD drive, if you have a DVD-R, or you could do a pen drive. So that’s the one thing that needs to come off of that machine before it gets wiped. You can have a whole ceremony where you go Office Space on it and beat it up with a baseball bat and burn it if you prefer.

# Verifying receive addresses

SL: Haha if you want to go hardcore. Then now we’ve initialized our three hardware wallets or two hardware wallets and the Seedpicker. Now we’re going to do the coordinate multisig. So this is like the setup in Specter. So you feed into your Specter desktop, you create a new wallet and you’re feeding in that information. Then Specter desktop will give you that wallet file. The next step now is verifying receive addresses. So can you tell us a little bit about that?

MF: We want to make sure in the perfect case, if we really, really care, we want to be sure that our receive address belongs to our hardware wallets, to multiple of them. Let’s think about how this works and the attack because it’s very weird concept to say that 2-of-3 of these devices own something. That’s not really how our brains ever work in the real world. There’s a place somewhere and somebody owns it. Possession is nine tenths of the law as we like to say. Maybe there’s rules about who can go get that thing. But there’s sort of one thing in one place and multisig in Bitcoin is just totally different from this. There are 2-of-3 things and these things could exist anywhere in the world and there could be copies of them. We own three hardware wallets, or two and Seedpicker which is effectively our software hardware wallet. We want to know that two of them are our Coldcard and our Cobo and the third one is our Seedpicker. Because what a clever attacker could do before we receive funds is they could swap the address and they could trick us by showing us one hardware wallet that is a member of that 2-of-3, that is ours, and then the other two seeds belong to our attacker. We pull up on say a Trezor, we look at the address, the Trezor says “Yes this is a 2-of-3 and I am one of it.” You deposit funds and boom they’re instantly gone because the other two belong to your attacker. What’s nice about Coldcard and Cobo is that they both register the multisig as part of that setup and they both keep track of that. They both say “There are three. I am this one and these are what the other two are.” Then they can confirm that every single time you verify a receive address. Now that’s not a guarantee because if that Coldcard or Cobo was compromised and your computer was compromised, and you’re looking at a receive address and your computer is lying to you and your Coldcard or your Cobo is lying to you, well maybe it’s not the case. So maybe you don’t want to rely on that enough. Maybe you do need to get two of them in the 2-of-3 case. That’s a difficult one. That’s sort of a trade-off that you would weigh on each deposit. If you’re receiving a really small amount you might say “My Coldcard, or my Cobo says it’s valid. My computer says it’s valid although that’s connected to the internet. They all register the same quorum. I think I’m going to say this is good enough. I’m just going to check the one of them.” But maybe you’re Michael Saylor and you’re receiving 425 million dollars. I think you are definitely going to check at least two of them and probably you’re just going to check all three because you want to be really sure. Probably in that case you’re doing 3-of-5 anyway. I think we know that they’re doing custodial Bitcoin IOUs somewhere but if he were doing it he would be checking on a quorum of his devices.

# Backing up all your pubkeys

SL: Now let’s talk about backups. There’s a few different things to think about here. I guess there’s two parts so let’s split it up. We’ve got public keys and then we’ve got seeds. So let’s start with public keys. How do we do backups on our public keys here?

MF: This is one of the footgun areas for multisig that is a little bit hard. You have to know this, you have to remember this, it is essential information. You must store all of your public keys and their related paths to be able to spend any of your funds. So you not only need the 2-of-3 seeds. You need 3-of-3 of your pubkeys and related path information. That’s kind of annoying because people tend to think “I have 2-of-3 multisig. I’ll back up my seeds and I can guard two of them and be sure that I’ll have two of them no matter what, I got that. I’ll put say the pubkey information with each seed. But I’ll just put the pubkey for that seed with that seed. The problem is if you didn’t have all three of your seeds would you have all three of your pubkeys and related information? The recommendation that I have in this guide is that unless you’re an expert user you should put all of your pubkeys with each of your seeds. If you have a backup of seed A, with that backup of seed A, say etched in metal, on a USB drive you have pubkey A, B and C and all of its related metadata. Specter desktop makes that really easy. One click export, put it on a USB pen drive, put it in the vault. But that is one extra step, 2-of-3 is not enough. You need 2-of-3 plus all of your pubkey information. This does present a new negative that is unfortunate, which is that pubkey information doxes some of your privacy. Imagine this was sitting in a safety deposit box and a banker looks you up and says “Stephan Livera, that guy, he’s a Bitcoin podcaster who is famous. I bet he has a lot of Bitcoin.” He drills the safe. Safety deposit boxes are a good place but nothing is a 100 percent secure. He drills the safe and inside he finds a list of all your pubkeys and he goes on the blockchain and he sees all the funds you have. That’s a little bit scary. Now we started from the premise that he drilled your safe. So that is already better than the single key situation where it was you had a seed phrase sitting there and they just stole all your Bitcoin. But now he knows “This is how much Bitcoin you have. Maybe I know your home address or your work address. I have one of your seeds. Now I’m going to go try to find the other one.” That’s one thing that is not perfect. There is an improvement on the horizon for this where you could do some sort of a quorum system where you needed like two locations to be compromised in order to get any pubkey information. But that has to do with a longer discussion on BIP 32 paths.

SL: And that’s probably a bit more advanced. But I guess the high level way to think of this is do your set up and save that JSON file from Specter Wallet into a USB key and have three USB keys all with that same JSON file. Back that up in all those locations such that if you were to lose one of your seeds you’re still okay. So long as you still have a spending quorum i.e. 2-of-3 or 3-of-5. I was careful to stress that point also in my interview with Stepan talking about Specter Wallet. Just to make sure everyone’s doing their backups correctly. That’s pubkeys. Now let’s talk about seed backups.

MF: While we’re on the pubkeys, I would add they’re literally called public keys. This is only privacy information. You can take that as far as you are comfortable with. You may decide I’m going to put that in my Dropbox, in my Google Drive, in my Mosey or Carbonite. I might give a copy to my accountant or my lawyer. I might want a lot of copies of that out there. Maybe with some encryption, maybe not. You might be a person who is very private or says “No way do I want all those people to be able to see all my transactions or Google or Apple’s cloud to be able to snoop and see that.” That would be a personal choice. I think probably you want to err on the side of more backups than less. But maybe you just want lots of pen drives and that’s fine too. But you have to have all of your pubkeys to be able to spend any of your Bitcoin. That’s really important.

# Backing up your seeds

SL: Moving onto seeds now. This is another example where depending on how your setup, you might be just writing it on paper or you might have it on a metal product. I guess you’ve just got to back those up as well. Are there any other tips you wanted to share on that?

MF: Just a really big one that safety deposit boxes are a great hack. Not for all of your seeds obviously in the m-of-n system. I wouldn’t want m of my seeds there but maybe m -1. They’re really great because they have a natural transfer if you die. They’re really good for inheritance. If you gave one seed to family member A, or even better they generated it themselves, and then you put another seed in a safety deposit box and you said “This safety deposit box goes to family member A if something happens to me.” That’s pretty good. It’s not perfect but it’s pretty good.

# Sending flow

SL: Now let’s talk through the sending flow. Let’s say I want to spend some Bitcoin or I want to send it to myself in some other setup. What does the flow look like there?

MF: The flow here is actually awesome and really easy. Everything we’ve been talking about is all the negatives and the gotchas and what’s complicated. The beauty is you set it all up so that it’s really, really easy. Basically you’d go on Specter desktop and you’d say “This is what I want to send. It’s like this much to this address.” Because it’s connected directly to Bitcoin Core it can do a lot of the fancy Bitcoin Core features when it comes to fee estimation or coin control or batching or whatnot. You put in the address, the amount and you hit this button that is Create Unsigned Transaction. That’s an important concept in PSBT. PSBT stands for Partially Signed Bitcoin Transactions. The idea is that these transactions have different states. At the beginning they’re just totally unsigned. Then you might collect one signature of say two that you need on one device. Then you’d go do it on another device and then you’re fully signed and you broadcast it. As far as collecting them on the devices it’s really straightforward. You can do it on the Cobo just by scanning QR codes. It pops up on your screen and says “Hey do you really want to send X Bitcoin to address Y?” That is the UI that we all know and are comfortable with. You double checked to make sure that’s really the right address. It’s going to do all the change detection and that kind of stuff for you. You hit send and it’s going to send that signature back to Specter. Specter will say “I’ve collected another signature.” You go to your Coldcard and you do the same thing. Advanced users can do it over the SD card. Novice users will probably just do it through plugged in via USB. On the screen of the Coldcard will be the same thing. “Do you want to send you know X Bitcoin to Y address?” It’ll verify the change for you automatically, you don’t really have to think about that. You hit Yes. Your signature is now sent back to Specter and Specter would say “Great. I’ve collected 2 of 2 needed signatures.” Hit the button to broadcast to the blockchain and off it goes. That might sound like a mouthful but it’s really go on Specter, say what you want to send and then validate it on two of your devices. Specter works really well because of this saving the state across multiple signatures. Maybe one device is kept there on premise in your home or work and the other device might be like a safety deposit box or something like that. Because it’s keeping track of the state you could say “I’ve got 1 of 2 signatures. I’m going to take this piece of information in my safety deposit box and do a signature and then bring it back and now I’ll collect it and broadcast. This actually works very intuitively. This is the easy part.

# Maintaining the setup

SL: Fantastic. Now let’s talk about maintaining that setup over time because I think this is another area where people might not think so much about. They’re just thinking “I’ll just set up the multisig and that’s it.” But in reality you’ve also got to maintain that through time. I know the guided providers, Casa or my sponsor Unchained Capital, they have some form of a concept around periodic key checking or health checking. You periodically go and check that there’s been no bit rot, things like that. Do you have any suggestions around that?

MF: Te services are good because they can force you to do this. It is almost like going to the gym, nobody’s like “Today’s the day. I really am excited to go check my backups and make sure they’re still there.” By performing a signature it’s sort of the ultimate proof because you’ve used the private key. You don’t have to be so formal about it. You can just go visit your safety deposit box and see that you have your seed still there. That’s enough. If the hardware wallet device failed you could put the seed on another hardware wallet. I like that they formalize it and have a process but you’re backing up your seed phrases for this very reason. If anything goes wrong with one of your devices you can always load this into another device. Even in the extreme, it’s not the easiest to use but you could load this seed into Electrum and use that to sign. It is not so much about the devices and whether it’s still performing well. It is really just about do you have m-of-n of your seeds. You want to check all your seeds with some frequency. Maybe you check monthly, maybe you check yearly. It depends on how you see the risks. Maybe you have a seed that’s buried in a mountain and it’s not so easy to dig up. Maybe you have a seed that’s sitting on your desk and check it every day. That’s a personal thing. But what you really want to make sure is that you have those collection of all your pubkeys which is going to be on your Specter desktop machine and savable as a JSON file. And you have at least m of your seeds but really you should have all n of your seeds. You want to go be checking that but those are backed up on paper or preferably etched into metal.

# Hardware wallet firmware updates

SL: Another point that has come up and we’ve seen recent examples of this, sometimes there are vulnerabilities disclosed in a hardware wallet and then the vendor releases a patch for it. For example, Trezor had a SegWit bug and Trezor put out a patch. Frustratingly there were some cases where there were downstream impacts to other companies like Casa, BTCPay Server and other projects. This is another thing we have to think about when we’re doing multisignature because there is a risk of your hardware wallet wiping while doing the firmware update. But I suppose to your point that’s also why we have the backup of the seed.

MF: Never perform a firmware update unless you’re sure you have all n of your seeds. If you only have m of your n seeds meaning losing a seed would cause you problems, first of all get yourself to a system where you have all n of your seeds. You should always have all of your seeds. If there was a fire or flood or something and you lost a seed the immediate step one is that you need to have all of your seeds. You need to regenerate a new one and add it to your quorum and cycle out the old one. That’s the most important. But if you’re ever in a position like that where you’re exposed, do not update your firmware. That is the time when things can go wrong. This is another thing that I’ll point out that is good about the Cobo and Coldcard BIP 174 native design. Because they’re designed around being air gapped and having the signature step be very explicit, one piece of data gets passed back and then the signature gets returned. Because they’re designed that way they don’t interact with a web browser. There’s not a Trezor bridge type situation that could be pushing a user to do an update. In the extreme case, Casa tells their customers not to ever update their firmware which is a little bit weird. You want to update and have the latest software always. That’s a good security feature but I believe that’s because Trezor pushed this firmware change that basically broke their customers’ access to their funds if they were to update. This gets into this nuanced and very detailed thing about BIP 32 paths which is a much more complicated issue. As a rule Bitcoin is designed to work forever. That’s what’s really cool. Bitcoin is security conscious. It’s always backwards compatible. I can’t think of anything that I would say you need to upgrade for but upgrading is always a good best practice. I’m sure there will be better user interfaces. The idea is you shouldn’t feel like you’re in a hurry to update but updating is still a good practice. If you’re using something like Casa or Coldcard if you have a strong air gap the device isn’t even going to know that it needs to be updated. That’s something that’s fundamentally different. So updates are unfortunately nuanced. Generally you want to do it but maybe you don’t want to be first. You definitely want to be sure it’s not going to cut off access to your funds. If you’re using something that’s designed around air gapping then it’s probably going to be less likely to affect you. That’s part of the reason why Coldcard and Cobo are what I recommend using. I should say about that. I get nothing from any of these companies. Coldcard has given me two of their devices. Cobo has given me two but one is to give to another developer although they did just say that they would send me another because I want to use it for my personal Bitcoin. But I don’t get paid anything by any of these guys nor for this guide or any of the software. I just love Bitcoin.

# Outstanding research

SL: That’s great. I guess we’ve spoken through the guide there and we’ve given most of the tips around how you should maintain the setup in terms of outstanding problems or research or development that you’d like to see. Is there anything you can share there?

MF: I think the really big one is going to be around BIP 32 paths because it just touches a lot of stuff. There’s a security vulnerability where a wallet could hide your change in a BIP 32 path that isn’t the one you were intending and this BIP 32 path could actually be a very large number. It could make finding your change effectively impossible. You could be ransomed to find your own change. That’s the attack. That’s where a lot of the controversy is. That’s part of the reason why for example address exploration in multisig on Coldcard isn’t that well supported with the air gap. If you allow for more paths then there’s more room for things to go wrong. What’s really cool with paths though is you could use it for different protocols. One for example is an inheritance protocol that I really want to see developed where you take a trusted third party and you say “Hey I want this person to have one of my five keys. They’re a close family friend. I trust them. If something happens to me they’re going to help my family get this Bitcoin. I want them to be one of the keys but I don’t want them to see any of my balances or transactions. I only want them to have access to that info if I get hit by a bus and they’re called upon to use their key in a transaction.” You could see a mechanism in the future with multisig where that person has a key, you can think of it as like an xpub. But the path is something that you keep. You give that path to your family and you say “If something happens to me this person has one key. They don’t know the path. Take this info to them and they’ll have the path.” By the way that will authenticate you as the heir so to speak. But probably you know each other. It sort of adds a level of protection. If you didn’t want to give somebody a key because they’re not good at private key security but you didn’t want to give a friend access to see your coins in terms of a privacy perspective, this is a neat way to meet in the middle. Only if both were hacked would they get one of your five keys. I could see these inheritance protocols morphing into some sort of collaborative custody that’s not that different from Unchained or Casa’s model of controlling one or more keys.But it could be anyone. It could be your kids. It could be a service that maybe even see Bitcoin influencers say “’ll guard one of your keys and if you ever need me to use it I’m going to take a 5 percent fee or a 10 percent fee. You can immediately start increasing the size of your multisig. From their perspective it would just be one more path along a key they already guard. The other one with BIP 32 paths is that if we use different BIP 32 paths for every wallet then we could reduce the situation where somebody who gets one of your seeds can see your transaction history. Of course you’d have to keep the BIP 32 path info separate from the seed so it introduces some messiness. It would only really work if it was tied to an inheritance protocol. There was extra redundancy there but I could see that improving both privacy and security which I really like.

# Future defense against the chosen nonce attack

SL: It sounds like that’s a little ways off right now. But it’s a potential future research or development area that we might see. How about defense versus the chosen nonce attack? Do you see anything coming down the pipeline for that or is it basically we’re stuck with using multisig to stop that?

MF: For now I would say multisig is the only thing that I know that even really tries. Personally in single cases in the past I always inspect the k value code to see how is that k value generated. The best practice, correct way to do it is to use the hash of the private key. That has an extra property that it’s deterministic so that private key will always hash to the same thing. The k value will always be the same. If you perform the signature twice on two different devices that both have that private key then you can guarantee that at least it’s using the same nonce. You can just eyeball that. So that’s something that I’ve done in the past but obviously that’s a very weak guarantee. There is a protocol that Stepan of Specter has written about where you could prove that your randomness was used in the nonce and that would be really cool. If that gets released then that becomes a must have. Certainly for single sig but even for multisig it would be very neat to add that. That doesn’t exist yet but that’s sort of the only one on the horizon. You even see extra weirdness because if you want to be a FIPs certified device and you’re at a certain level, I don’t remember which level it is, but I think it’s like if FIPs 140 Level 3 then you’re supposed to use a true random number generator. You’re not supposed to use a deterministic k value. So the true random number generator uses a source of randomness that’s dedicated and supposed to be good at that. That is good. The problem is you can’t verify it in the same way that you could with a deterministic nonce. Even some of the really good ones, they don’t use deterministic k values because they’re FIPs certified. I just think the answer is going to be multisig on this because this is so complicated and difficult and multisig just solves it.

# MuSig2 interactivity

Blockstream blog post: https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295

SL: For most people it might not be worthwhile that rather than just using multisig. Also obviously the Taproot soft fork is under discussion right now. No activation has been proposed for it yet but let’s say in a year or so maybe we get it. I know that Taproot introduces a whole new world in terms of possibilities. Some of the guys at Blockstream and I think other collaborators are working on what’s called MuSig2 which is a new way to do multisig. But as I understand Taproot can introduce more interactivity and so that would change how people use multisignature and hardware wallets. Do you have any thoughts on what that would look like?

MF: The last time I dug deep into the code on this was maybe nine months ago. It was a working version then or proof of concept that could change. I know there were some minor changes at least since then. I’m definitely not an expert. I don’t want to claim to know more than I do. That version used these tweaking factors where you had an extra round of interactivity. Whereas in this setup each device presents its public key and that’s just enough. If you have these tweaks each one has to present a challenge that the other one responds to and proves that it used that nonce. It effectively makes it more of a pain to set up. That’s kind of a negative. The flip side is you get these really powerful spending conditions. You can do any m-of-n. In Bitcoin land under the current scripting, beyond 3-of-5, 4-of-5 those types of situations, the transactions get very big. Whereas in this when you use Taproot you can do an infinite number or nearly infinite number of conditions. You have a Merkle tree similar to the way Bitcoin transactions are included in the blocks. Basically everything shows up as 2-of-2 even if it’s 2-of-3. You get three different 2-of-2 branches and then you reveal the branch to the correct one that you’re spending from. If you’re spending from AB you reveal the branch to AB and it’s a 2-of-2. But if you were spending from BC you reveal the branch to BC and that’s also a 2-of-2, it’s just B and C. That’s a very neat thing cryptographically and you could have an enormous number of spending conditions. But keep in mind we already can do these with like OP_IF and OP_ELSE. It would be totally possible right now to have a script template where you said “For the next five years I want these funds to be guarded with this 3-of-5. But after that, for the next five years I want them to be guarded by this 2-of-3. After that as a failsafe this 1-of-1 is good enough. After that, now we’re at 10 years or 20 years in the future, for emergency recovery any one of the keys we’ve talked about, any one of the nine would be enough for emergency recovery.” You could already do something like that. You just pay a big transaction fee and you’d reveal a lot of that information when you go to spend. These improvements are definitely improvements and they are better. You would get better transaction fee savings and there’s a little bit more privacy. But in terms of security you want multiple hardware vendors that support this. We’re just taking years to get the basics out.
I think it’s going to be a really long time before we have multi vendor hardware wallet support. I would love to be wrong about that. But I don’t think this use case should hold anyone up. If you care about securing your Bitcoin but Taproot is going to come along in some number of months or years, it doesn’t stop you from upgrading then too. But the hardware wallet support is going to be very poor I would imagine for a long time when it does get merged in, if it does get merged.

# Using GIFs to extend QR codes

SL: It’ll be a process there. One other topic that is interesting is around QR codes. There’s been some discussion is that if you were to try to transmit a PSBT through a QR code, let’s say it’s a very big transaction, that might now require multiple QR codes. There’s a little bit of research being done. I know the Blockchain Commons guys like Christopher Allen are working on this idea of having a GIF that transmits through QR codes to get more data through. Do you have any thoughts on that? How essential would that be particularly if it’s a big transaction?

MF: This basically exists now and is in the setup that I recommend. That’s pretty awesome. Specter desktop will relay QR GIFs to Cobo Vault and it just works. It’s really cool. The problem tends to come around inputs because inputs take up a lot of space. If you have a lot of inputs you’re going to have a lot of data. Too much data doesn’t really fit in one QR code and so Cobo supports this and I imagine others will in the future. It is just so much better than the alternative ways. The USB stack is terribly insecure. Stuxnet showed us that SD cards could be vulnerable although SD cards are better than USB pen drive. Stuxnet was on pen drives, that’s an important distinction. But QR is great. It is true that the more data you pass through a QR code the less verifiable it is. If it’s a QR GIF that’s a hundred images you’re probably not going to validate what that is. You’re just going to hold it up and it’s going to run whatever it does. At some size you do have to worry about these vulnerabilities. Maybe there’s a buffer overflow and the QR code is going to take advantage of that. Then it’s going to give it software to run that’s malware. But in practice we’re talking about very small amounts of data. This only matters in these hundred input situations that are incredibly rare. Most people do not have a hundred UTXOs and if they do they’re not using them in one transaction. It is not a zero risk but QR GIFs work great. If you’ve ever used a QR based hardware wallet it is a magical experience. Once you do you’re just like “This is what every hardware wallet needs to be.”

# Impact of open source secure element

SL: That’s cool. I guess even in that high number of inputs scenario what you could do, not optimal but in order to save your funds, you could periodically consolidate or break it down into smaller transactions in terms of inputs if you really needed to. It is not the end of the world but that’s there. Also as this space grows up, right now Bitcoin is tiny, we’re talking 200 billion dollar market cap. The open source secure element, people are chasing after this idea potentially in the future once the space grows up. Does that in your view help much or it doesn’t matter that much if you take the right steps?

MF: That would be really cool. I would love to see an open source secure element. That said multisig makes this not a big deal. We can already prevent against so much by just adopting good multisig and it’s now available. Historically it was like a theoretical thing but now it’s just real. In order for these secure elements to be useful they have to have PINs and that’s part of their whole magic is that you only have so many attempts and then this thing’s going to lock you out. That’s what gives you your physical security. The physical security requirement kind of changes in a multisig world. You’re probably just going to keep seed phrases in multiple places laying around, safety deposit box and buried in a mountain type thing but still there’s no encryption. Somebody who sees that seed phrase can just use it. You could do the deniability with passphrase but the point being that for secure elements to really be useful you need these PINs. The PIN presents a new issue. I think open source secure elements are the type of thing that we will see happen at some point. It will be awesome. I’ll want to have that as part of my quorum. But it won’t be a game changer.

# DIY vs Providers

SL: Gotcha. High level if we were to summarize. What we’ve spoken through is DIY multisig, doing it yourself. What’s your high level view on doing this DIY style versus using the guided providers such as Unchained or Casa?

MF: I think the guided multisig services are really good versus custodial services, for both large amounts and non-technical users. Think like a wealthy individual family office, MicroStrategy is a great example, they’re sitting on a bunch of Bitcoin right now. I think about the guided services as a great first step to get off of custodial. They make it way easier for newbies. They have this incentive to push their best practices. So things like the health or key check, make key rotation really easy. That’s a scary moment where you need to not mess up the most. In theory they’re really good for inheritance. There are some KYC issues with that. If they need to know who to co-sign for if something happens to you then they need to know who you are. Obviously there’s KYC with one of these services, at least if you’re going to go the inheritance route. So they do offer a lot of these good things. There’s kind of an asterisk in my mind about where they are right now in that it’s just limited hardware wallet support. So Unchained doesn’t support Coldcard or Cobo and Casa doesn’t support Cobo. Once they’ve fixed that there’s some generic things that you should be aware of. You’re going to give up all your UTXO privacy with one of these services. They have to be able to see all your transactions and balances and they make your life a lot easier. That’s sort of the trade-off but you can’t use them without giving up your UTXO privacy, Casa will let you use them totally anonymously. You can just give them a not your name domain email address and you can sign up that way. That’s neat but they’ll still know all your transactions. They also have to be careful because these services are kind of in a position to trick you. If you really know what you’re doing you’d catch them. But if you really know what you’re doing you probably would be doing it yourself. So an example of this is let’s say it’s a 2-of-3 and they mailed you one of the hardware wallets. That hardware wallet is a Trezor that doesn’t register the rest of the quorum. When you go to verify deposit address which they show you on their website and you verify it on the Trezor, you verified one of three but they could have the other two. I don’t think that they would do this. There’d have to be a lot of people in on it. This is only when you’re depositing but it’s an example that’s like “I don’t want to be in the trust business.” You kind of have to be a customer of theirs and be skeptical. It is not great if they’re mailing you the hardware wallets directly. You should be buying them from the manufacturers. There’s a lot of these little details where they’re going to want to do it the easy way because it’s easier for you and they know they’re not trying to trick you. But your security model can start to blend a little bit. If they’re giving you the devices and they already have the seeds on them and they’re showing you the deposit addresses on the screen it starts to be like “How much of this is me and how much of this is them?”

SL: One other point is when you are accessing your setup. Let’s say we do this setup and you’ve got the three different keys distributed into three different locations. You also have to think about how you’re actually doing the signing process because you wouldn’t necessarily want to have a quorum in one place at any one time. The difficulty then would be how do you access back to your Specter when you’re at the remote location? Unless the setup is you have Specter at your home and you have three separate locations. You individually go get Key 1, bring it back to your home and sign it and then put it back in the location. Then go get key 2. You see what I’m saying?

MF: Yeah. It’s unfortunately a tricky one that everyone has to think through these locations for them. It might even be in an extreme case that you have different wallets. You have one that’s your serious HODLing, your savings account so to speak that is 3-of-5. That is a real pain in the butt because you have to go to three different locations. Maybe one of them is your home and one’s your work. Maybe two of the locations are not that hard but the third one is tricky. You might want it to be tricky because you might want to be well guarded in the event. I know Bitcoiners when there were hurricanes in Florida that had to evacuate with their Bitcoin on them and that’s very uncomfortable. You might to be so well distributed for geological events or emergencies but then if you need access to them they’re really geographically far away. You don’t want to be having to fly to another country to sign a Bitcoin transaction. It can be a tricky one. You might need to preplan that this one is my long term. This is for my children, 3-of-5 and the five are all over the place. This one I’m going to do some shorter term trading or maybe I have business that gets paid in Bitcoin. I have to spend and receive Bitcoin regularly. For that maybe I’m only 2-of-3 and one of them’s at home and the other one’s at work or a safety deposit box and that’s going to be enough. Or you might even in an extreme case do 2-of-3 and keep two of the keys in one location. Obviously you introduce a single point of failure. But maybe one of them is a hardware wallet that you keep on your key chain and the other one is in a safe you have at home. Maybe that’s good enough for you. That’s kind of your own business.

SL: I guess then the other thing is accessing back to your Specter while you’re remote. Maybe some of this can be eased by the node package devices who set up a Tor hidden service that you can access while you’re out. I suppose that’s another area where you’ve got to think about how you’re going to phone back home to your own Bitcoin Core and Specter setup to actually do the setup. You might be remote where your key is and not being able to bring it back to your home where your node is.

MF: In practice if your Specter is on a laptop than if you need to do something really important like fly somewhere and put a key in a safety deposit box you could just bring the laptop with you because there’s no private key info that is on that laptop. Specter is really good about aggregating signatures. You grab one from one place and one from another. But where you’re going to get into tricky ones is if you’re going to sign many transactions with one key in a location that you travelled a long way to and you don’t want to travel there once for each transaction. You want to do a bunch of transactions but for whatever reason it’s not a batching situation. Maybe there’s a privacy element. You could get into something weird like this where honestly your easiest answer is just put Specter desktop on a laptop and take it with you and any edge case you can solve.

# Future contributions to 10x Security Guide

SL: That makes a lot of sense. Are there any points where you think the guide needs some work or improvements. What are you looking for in terms of contributions as well?

MF: I would love contributions. This has been a Herculean effort. I should probably stop creating tonness of work for myself where there isn’t a revenue model. PRs are very welcome. There’s all kinds of areas that have little to dos or fix me notes. If you want to add more screenshots to document things, add more detail or explanation, links to other sites. There’s all kinds of great tutorials and places where you can learn more. I’m trying to be the most streamlined where I give you more info if you need it but not overwhelm. Pull requests very welcome. The underlying software all has lots of room for user experience improvements. I expect that these things are going to keep being improved and iterated and then the guide will have to be adjusted for that. My design is terrible. If you’re a designer and you want to make it pretty that’s all welcome. Pull requests definitely welcome. I would prefer this isn’t just me.

SL: Maybe a quick high level. Let me summarize a few of the key points for listeners, just to make sure it’s all clear. Essentially you’ve got to get those two different hardware wallets and have either an offline computer or use Tails for your seed picker. You’re creating that multisignature using Specter desktop and Bitcoin Core. If you want that easy, you can use say myNode or one of those node packages. Then you create the multisignature, you back it up with that JSON file. You make sure you’ve got that well distributed. I guess kind the key points are checking the addresses on the device when you do those transactions, receiving and spending and so on. And periodically checking the setup. I guess those are some of the high level summary points. Anything else that you wanted to remind listeners?

MF: I think that’s well said, it sounds scary or daunting. I certainly understand that reaction. The thing that I cannot stress enough is that multisig allows you to make massive mistakes or at least one, potentially many and not lose funds. You don’t have to be totally freaked out at every step that you’re doing it wrong. Whereas in the single sig case I think you do. As much as this seems like a lot, blast through it. You don’t have to be as paranoid as you would be about say updating firmware in a single sig situation. It’s much more casual and that’s great. You can just focus on the Bitcoin stuff and not on the details.

SL: One other thing you could do is let’s say you’re already sitting on single signature right now and you’re paranoid and you’re like “What do I do?” What you could do is just try this multisig guide with a small amount. Try it with 10 dollars just to get comfortable with it. Then over time as things improve, as you become more confident in it, then that’s when you could start to more seriously use it for larger values.

MF: Definitely. A good example of opportunity to put new stuff in the guide, Testnet is a great place to do this. Cobo recently added support for testnet, Coldcard has had it forever. You can do all of this on testnet. I highly recommend it, testnet is free. You should practice a tonne. Testnet is your friend. You should definitely use testnet.

SL: You can get the guide at, it’ll be in the show notes btcguide.github.io and Michael where can people find you online?

MF: The best way to find me is on Twitter. It’s \@mflaxman and good luck storing your Bitcoin.

SL: Thank you very much for joining me.