Name: Michael Flaxman

Topic: Every Bitcoin Hardware Wallet Sucks

Location: Stephan Livera Podcast

Date: August 8th 2019

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

Transcript completed by: Stephan Livera Edited by: Michael Folkson

# Intro

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

Michael Flaxman (MF): Hi. It’s good to be here. Thank you for having me.

SL: Michael, I think you are one of these really underrated or under followed guys. I think a lot of the hardcore Bitcoiners know you but there’s a lot of people who don’t know you. Do you want to give an intro on yourself?

MF: Sure. I fly under the radar and that works just fine for me so I’m not looking to change anything. For some background, I’ve built three venture funded companies. Mostly I’m known for my first company thumbtack.com, which was in the press last week for achieving a 1.7 billion dollar valuation which is pretty neat. My next company was a Y Combinator company. It’s not nearly as successful but still around. Then in 2013 I got the Bitcoin bug and I started a Bitcoin company that died very fast. Now that I’ve learned all that I know about Bitcoin it’s kind of embarrassing. You get excited about a new thing and you want to build something. At the time we thought cold storage as a service was a great idea. Now I’m going to talk to you all about why you should store your own Bitcoin. I started building Bitcoin apps in 2013. I was a very minor contributor to [pycoin](https://github.com/richardkiss/pycoin). In 2015, I wrote BlockCypher’s block explorer which I don’t think is maintained. I’m not sure. I know people still use it for some stuff. I should pull the traffic numbers because I think I still have access to the Google Analytics. Last time I looked at it it was like eight figure page views per month which was just wild. It is not something that I’m involved in and haven’t been for many years. In 2016 I wrote their [command line wallet](https://github.com/blockcypher/bcwallet) and I’ve written a number of Bitcoin wallets over the years. The BlockCypher command line wallet is just for fun. It’s not something you should use for real money although it does support testnet so I do recommend it as a testnet wallet. Its claim to fame is it’s the shortest number of lines of code of any Bitcoin wallet. At the time it did some cool, advanced features. In 2016, to have a wallet that did fee preference is neat.

SL: That’s definitely ahead of its time.

MF: You really see how does Bitcoin work. Now there’s a lot more resources. You can take Jimmy Song’s Programming Blockchain class, you can take Justin Moon’s Buidl Bootcamp. There’s a lot of resources to see how you can do something but historically you can read Bitcoin Core which is very, very difficult to read and very, very long or you’re drifting around on the internet. Having resources where you can see how to generate Bitcoin addresses and sign the transaction and that kind of thing is pretty cool.

SL: Fantastic. I know you were recently helping Jimmy on his Programming Bitcoin course as well as a teaching assistant. You provide technical review and feedback as well.

MF: Yeah I’ve known Jimmy since before he was a crypto guru if that’s the right word. We were both minor contributors to Richard Kiss’ pycoin, the Python Bitcoin library, in 2013. I met him in February 2014 at the Texas Bitcoin Conference which is kind of wild. Then we ended up working together at Paxos. He just writes really good code. He’s a joy as a software engineer to work with. He’s super, super talented. I almost feel bad that he’s not really writing code anymore. That’s not totally true, he’s teaching people and he does write code for some other things but he is so gifted at that. It’s almost sad that neither he nor I are writing code full time anymore. That’s how I met Jimmy and I read his very first blog post and pretty much every one since. I thought it was neat that now he has 100,000 or probably much more Twitter followers and a YouTube channel and he travels the world teaching about Bitcoin. I helped him as a teaching assistant in a couple of classes but it’s never been my venture. I do it for free. My policies were business class flights and steak dinners and I’ll happily go meet Bitcoiners in other cities which is pretty fun. I was a technical reviewer on his O’Reilly book as well.

# Difficulty of securing Bitcoin

SL: Excellent. Let’s get into our topic for today which is hardware wallets and why a lot of them are not secure. There are certain mitigations as I’m sure we’ll get into. Let’s talk a bit about some of the difficulties involved. Why is it so difficult to secure your Bitcoin?

MF: Before we get into this whole episode bashing hardware wallets which I enthusiastically stand behind, for most people they are the best choice. If you’re owning Bitcoin I strongly advocate holding your own keys and unless you’re an expert you should use a hardware wallet. If you are an expert you should build your own hardware wallet with open source software that’s free and equipment that you source yourself but that’s way outside the scope of this. For most people hardware wallets still are the best choice as far as usability and security, and they’re reasonably priced. We’re talking around 100 dollars but they are very hard still. I don’t want to scare people into something less secure but you should be eyes wide open that there are no bailouts in Bitcoin. There’s no undo button. If you mess up you can lose money. That really, really sucks. A lot of Bitcoiners who have been in this space for a long time and know what they’re doing have a story about how years ago I lost …, the numbers could be 0.1 Bitcoin but a number of people have come to me with 100 Bitcoin losses and I’m just like “Ouch, that sucks.” Use testnet, do everything on testnet first. Try it multiple times, wipe your device, recover. Testnet is a fantastic resource because it’s the same thing, it’s just not worth anything so you get to practice. Use a hardware wallet and use testnet first. With that said your question was why is it so hard to store a Bitcoin even on a hardware wallet? Getting back to that you really have to think about what are the odds that you’re going to mess this up? They’re very low. Just using a ordinary hardware wallet without any special skills but being savvy and cautious and sending a transaction, I would guess that there’s somewhere between a 0.01 and a 0.1 percent chance you’re going to lose money. Those are pretty low numbers. If I told you you were going to hit the Facebook like button and it was only going to fail 0.01 percent or 0.1 percent of the time you wouldn’t think ‘Which browser am I using? Have I validated the software? Do I click it this way? How long do I hold it down for?” You would just hit the button because that’s totally fine. But if your Facebook like didn’t stick you also wouldn’t care. If you were transporting a very significant amount of money to you, perhaps you are leaving your homeland and this is your life savings, finding out that 0.01 percent of time you lost all your money, that’s really, really not ok. It brings us to this weird place where if you told me to pay an extra 0.01 percent transaction fee I would guarantee that nothing bad would happen, this is super hypothetical, there is no way to really guarantee this. But if you told me that I would probably say “Yeah, I’ll pay that fee all day long.” If I could get that guarantee and I’m just going to lose 0.01 percent I’d pay it. But unfortunately if you’re the 0.01 percent of times that it happens it 100 percent affects you. That’s why it’s so, so scary. If you’ve ever done a large wire for something like buying property for example, you probably called the title office and said, “Hey. This is the wire information. I’m getting this email from this person who I think is a title officer but now I’m just calling the main line and making sure this is a real company.” There’s moments like that even though a wire is perhaps more reversible depending on your situation. With Bitcoin you have that same fear and it’s designed for storing large amounts of value so this should be really magnifying. Everyone has this moment of terror when they go into their cold storage to sign a transaction. If they don’t they’re probably being reckless. They probably should. Lots of people didn’t claim their Bcash or other altcoin airdrops because it’s just like “For 10 percent I’m not going to touch it”. Whatever the number was. At some point it got much, much higher and now it’s much lower. But for some people, it still wasn’t worth it to them. That is really, really hard. In terms of the things that you have to get right, because that was really your question, is this code doing what I think it’s doing and am I running the code that I think I’m running? Both of those are incredibly hard things to verify. There are just so many famous examples of hacks and bugs that it’s hard to point to all of them. There’s lots of other talks that’ll give examples of those. The idea is that you should be cautious and paranoid because it is really hard. 

# SecureRandom bug in 2013

MF: One of my favorite examples is there was a [bug](https://crypto.stackexchange.com/questions/9694/technical-details-of-attack-on-android-bitcoin-usage-of-securerandom) in 2013 in Android’s implementation of SecureRandom in Java. SecureRandom, as the name suggests, is a function that securely gets you some random bits of data. In a Bitcoin signature you need a random component. It’s part of the proof in the ECDSA signature. If that bit is random it’s not something that you ever would look at again. You can think of it as a nonce, a number used only once. It just is used to prove your ownership of that private key. But if that secure random data is actually not random then somebody could intuit your private key instantly. This is not a difficult attack to do by any measure. There’s plenty of open source code that will do it from your signature. As soon as they see a signature broadcast they know your private key and that is terrifying. A lot of people lost money in wallets that were Android wallets in 2013. That’s the type of thing that nobody could possibly have been aware of. It’s the job, a library for randomness, it’s called SecureRandom. Developers who used it were doing the right thing. Then surprise you lost your money. Those are the types of examples. Now they’ve since fixed that, that was 2013. 

# BitGo recovery script bug in 2015

MF: Even BitGo, which is a very reputable company, I’m not meaning to say anything negative about them specifically, they had a [recovery script](https://github.com/BitGo/bitgo-recovery-tool) so that you could access your funds if they went out of business, which is excellent. It was open source. They employed really smart software engineers. They’d been around for a long time. The code had been open source for a long time. [Somebody](https://www.reddit.com/r/Bitcoin/comments/33u2id/help_losing_over_85_btc_because_of_bitgos_flawed/) ran the script and lost 85 Bitcoin. This was in April 2015. To BitGo’s credit, they made that person whole. They reached into their own pocket and recovered that person’s money. But ouch. If you just ran some code and one minute you’re thinking, “Okay, I’m going to send this money,” and the next you’re like “Where did 85 Bitcoin go?” that hurts. You should never have a moment like that. When planes take off and land we don’t say “There’s only a 0.1 percent chance it’s going to crash you’ll probably be fine.” We have all kinds of redundancies and checklists. It’s a different thing. It’s not move fast and break things but it works really, really well. In Bitcoin one day we’ll get there. We are getting better and better every year.

# Electrum bug in 2018

SL: There’s the examples where it was an honest mistake and then you’ve got the examples where it’s malicious. Somebody is trying to compromise you in some way, make you run different code that potentially is malware.

MF: Exactly. We saw this in Electrum for example, December 2018. Electrum is a great piece of software. I recommend it. I’m not saying that it’s bad but somebody figured out that there was a mechanism to send a message, if you run an Electrum server, and we don’t know who runs the Electrum servers and big PSA. They’re probably run by Chainalysis. It would be the best guess. You should assume you’re just connecting to a government repository of address info when you connect to an Electrum server. If you use Electrum it is highly recommended to run your own Electrum server which is a pain in the butt. But when you connect to a server it can send you any message it wants. It was clever and sent a message saying “Hey your Electrum is out of date. Click here to update.” The thing that you were updating to was actually their version of Electrum that stole your money. This [bug](https://bitcointalk.org/index.php?topic=5150024.0), to this day, persists in Electrum in a weird way. Now Electrum servers can’t send you that message on a new version of Electrum. Also to enforce upgrading, Electrum servers won’t connect to outdated versions of Electrum clients so you have to upgrade your Electrum client or you’re only going to connect to malware servers.

# Securely installing Bitcoin software

Luke Dashjr on how to securely install Bitcoin Core: https://medium.com/@lukedashjr/how-to-securely-install-bitcoin-9bfeca7d3b2a

SL: My listeners are at different levels. We have some beginners and some intermediate or advanced level. But in that example, theoretically, what people should be doing is when they download this new software they should GPG verifying right? They should be verifying the software release is signed by the private key of a known developer. In this example, Thomas Voegtlin. Theoretically they should be checking that this upgrade signature matches but in practice not many people do that.

MF: Exactly. This is where private key management gets really, really hard. Each thing that you say “Hey, it’s probably fine. I downloaded it from the Electrum website.” You want to be really sure. “Was it actually the Electrum website or was it some imposter? Did you have an SSL certificate? Because if you didn’t then perhaps there was a man in the middle serving you a malicious copy of the Electrum client. These are not nefarious, farfetched attacks. There’s a really strong incentive to do this. If you are a talented hacker and you’re not a white hat hacker who works for companies securing them. You want to be a black hat hacker who steals there is no better use than cryptocurrency. It used to be if you broke into people’s computers you could send some spammy message to their friends saying “Hey, buy this Rolex” or something. Nobody did because it is obviously spam and it’s weird. Some percentage of people did. They send billions of these messages, the overwhelming majority get caught in spam filters. Then of the remainder, some people, some very small percentage, would buy these fake Rolexes with iTunes gift cards or whatever the crazy scheme was. That’s a really difficult way to monetize malware. Now, if you’re a smart hacker you want to get into people’s Bitcoin software. There are so many clever attacks. I could potentially serve somebody up a Bitcoin wallet that is malware and then they’re completely under your control. But you might do something more subtle where you’re able to trick them into thinking that this is their receiving address when it’s actually the attacker’s receiving address. That’s a very common attack. You might be able to mess with their source of randomness. They’re still running their software but they’re not getting the proper randomness. At every step of the way you should do these things. You should absolutely verify signatures of software you’re running but it goes to show how really hard it is. You can only improve the probability that your system is secure. You’re never going to be at 100 percent. If you’re doing a Bitcoin transaction it’s probably because it’s something that you relied on to store value and you would really like 100 percent. The thing that we’re going to talk about in a bit is multisig. The benefit of multisig is that if you use two different hardware wallets or two different setups and you require two signatures, your numbers could be whatever you want, you could require 3-of-5 signatures, 4-of-5, 2-of-3, but if you use more than one signature then an attacker would have to exploit the vulnerabilities in more than one of those configurations simultaneously. You can take something that’s probably good enough that’s going to work 99.9 percent of the time or maybe even 99.99 percent of the time with something like say a Trezor. Then you can do the same with something like a Coldcard. Then you get this additive benefit of multisig where now a hacker has to attack both of those systems simultaneously. That is not just twice as hard, that is orders of magnitude harder. That’s the thing we’re going to get to, the amazing power of multisig.

# Checking Bitcoin addresses on the hardware wallet

SL: Let’s talk through a few of the common ways that a hacker might try to compromise you. Another example might be if they had some malware that made you copy the wrong address and paste their own receiving address. That’s probably another example.

MF: That one’s really common. One thing about that is that you should always check the address in your most secure location, meaning your hardware wallet. One of the simplest attacks is to get you to copy, paste the wrong address on your machine and then just hit send on the hardware wallet. But really on the hardware wallet screen is the one that you need to confirm and you want to call that person up or however you securely communicate with them and say “Hey, I’m about to send you these funds. Here’s the address I’m seeing on the screen on my hardware wallet. Is this you?” A good attacker would be smart. They would make the beginning digits and the ending digits the same because us humans we’re very weak and we follow heuristics. Nobody wants to verify the entirety of a Bitcoin address. They say “Well, the first five characters look the same, the last five characters look the same, I’m going to call it a match.”

SL: How difficult is it computationally to make vanity addresses? Andreas famously has “1andreas” or something like that. It was more difficult to generate an address with specifically those characters you wanted. On this question of if you were to try and use this heuristic or shortcut as you say, the first few digits and the last few digits, do you have a feel or can you tell us how much more difficult it is that for a hacker to do? 

MF:The way Bitcoin address generation works is behind the scenes there’s this secret exponent. It’s a really large number between roughly 1 and 2^256 which is unfathomably large. We’re talking about more atoms than there are in the universe. If anyone can guess that number they steal your Bitcoin but again it’s such a big number that they could guess for the whole history of the universe and they wouldn’t get a fraction of the guessable space. It’s a really, really large amount of entropy. You start with this private key and you do a bunch of manipulations to it including hashing it twice with SHA-256, once with RIPEMD-160. You encode it in base58 or at least for a previous non-native SegWit address. You add a checksum, you do all this stuff and then you output an address that looks completely random. If somebody is trying to do a vanity address like the Andreas one, they’re just trying lots and lots of combinations. It’s not that dissimilar in your mind to think of as proof of work where you try a lot of combinations and then you see which one for a block hash has a bunch of leading zeros. If you look at a block hash it always has a lot of leading zeros. That’s because that’s actually a number representation of a really big number in hexadecimal so those leading zeros are proof that work was done that meets the difficulty threshold for Bitcoin. It’s a similar concept with the vanity address where you just try a bunch of stuff, you’re not targeting a difficulty number, you’re targeting “Can I get something that starts with this many digits and/or ends with these digits?” You can think of the difficulty as a function of the number of digits. Each extra digit you add gets exponentially harder. That’s why we have “1andreas” but we don’t have “1andreasantonopoulos”. I don’t want to say impossible because I would need to do the numbers for it but just off the top of my head I would say it’s probably impossible just to get that many digits. Typically you see vanity addresses I think going up to like 9-ish characters and each extra character is very expensive. You could try to set your threshold there but really just try to read the whole address. You’re a human that’s inaccurate and you’re going to miss some characters. If your attacker was clever and gave you an address where three of the first four digits were correct and three of the last four were correct you’d probably be fooled. It’s hard.

SL: That’s tough. Thank you for the explanation on that because I think that is another common heuristic that people already are using.

MF: You should always assume that your attacker is smarter than you and has more hardware than you because you’re not their only target. They’re doing this for everyone. They might have a GPU generating vanity addresses so you’d look at it and say “Wow, these eight digits match. That can’t possibly be a coincidence” but maybe that’s just what they’re really good at, making eight digits match because they have every financial incentive to do it.

# Supply chain risk

SL: Yeah that’s scary stuff. How about the supply chain risk as well? That’s another big factor that people talk about.

MF: The supply chain risk is absolutely terrifying because it’s completely outside your control. You could do things to minimize it. You say “Well I’m only going to buy my hardware wallet direct from the company at an event where they’re there.” If I get my device from a person who works at the company then that’s probably better odds than, absolutely do not buy it secondhand on eBay. That’s one way to minimize the supply chain risk but you can’t know about upstream supply chain risk. They’re not making it at home in their basement, they’re contracting out to a third party who’s taking commercial equipment off the shelf. There’s so much room upstream for there to be a vulnerability. One of the things that’s scary is, let’s say that there were a vulnerability, I’m not saying that there is but we should assume everything is compromised, you would have a financial incentive as the attacker to wait. Let a bunch of funds be deposited onto hardware wallet A, B or C where you know the private key. Once the number has gotten big enough, say you’re at over 100 million dollars, that’s when you have your retirement attack. You simultaneously drain all the funds and you disappear. No one would ever be able to know. The chip maker would point to the software, the software would point to the firmware. Everyone would just be pointing fingers and nobody could know. The whole system would break down. It’s a scary world out there. I do every tinfoil hat thing you can do and I assume that what I do is not 100 percent safe. It’s multisig that I think really changes the whole nature of the equation.

# Benefits of multisignature support on hardware wallets

SL: What does a good hardware wallet look like? I think a good place to start would be multisignature support. How does multisignature help?

MF: When multisig originally came out a lot of the use cases were around securing the private key material and the operational bit within a company. What that means is you could have a key at home, a key at work and a key buried in a treasure map somewhere in your favorite place. If you need two of those three keys, then somebody breaks into your home or your work or finds your buried treasure, they don’t get your Bitcoin. That’s one use case. Then the other bit is, maybe operationally you’re a company of three people, and you have two of three keys, so it takes two of three people to authorize spending funds. Or you could do this across organizations with a service like BitGo and you’d say, “Ok we need two of three keys, but one’s going to be owned by BitGo and one …” Or I’ll use an even better example, Unchained Capital. I think they’re a show sponsor if I remember correctly.

SL: They are yes.

MF: They’re here in Austin, Texas. Maybe Unchained has a key, you have a key and another custodian has a key. In a 2-of-3 situation, two of three of those entities would have to be hacked. That is true and multisig can provide benefits for that. What I’m really excited about multisig for is that you get independent hardware and software stacks. Those signatures could come from two hardware wallets sitting on your desk. But if one’s a Trezor and one’s a Coldcard now an attacker has to attack the supply chains of both those companies. Now an attacker has to attack the software implementation on both of those companies. Since those devices exist to distrust the host computer, they should be verifying everything themselves. That’s really good for your security. That’s an important thing to think about with a hardware wallet. The reason we have hardware wallets is because we assume that our host machines are infected with malware. That’s the reason we do it. If we thought our desktop computers were totally safe and secure, we wouldn’t need hardware wallets. Hardware wallets provide that extra level of defense. I’m sorry, I keep drifting off of your questions.

SL: That’s good. The other component you were mentioning is how you have to get everything right. If you’re trying to do just one hardware wallet, everything has to be right for you to have that same security. Can you touch on that point around just why it can help? For example, let’s say you use a Trezor and a Coldcard and let’s say unbeknownst to the company there was some kind of software hack in one of those teams, or one of those pieces of software that underlies those hardware wallets, how would you still be secured in a 2-of-3 scenario?

MF: This is often called m-of-n which is a threshold. You require m signatures of n total possible signatures. That’s something that the user can configure. You could decide you want 2-of-3. That’s probably the most common one that we see in the wild. You would say “Ok I have these three hardware wallets” and maybe it’s a Trezor, a Coldcard and a Cryptosteel, “and I need two of the three to sign.” It’s not that you specifically need the wallets to sign, you need pubkeys that those wallets hold to sign. You have these three devices and you want 2-of-3 of them to sign. If one of them is completely compromised, in the worst possible way, it’s not some edge case vulnerability that does one thing wrong in one case, assume it sends your private keys home to their server and they can just do anything they want. Maybe it even updated the device remotely so that they can control it. It’s just fully owned piece of hardware sitting on your desk. The worst, worst possible scenario. But your threshold was you needed 2-of-3 signatures, it just doesn’t do them any good. They have to hack a second device as well. The odds of that first scenario are pretty unlikely. To do the second as well is really, really tricky. It’s unlikely you’re the target. It’s not like somebody has concocted this unbelievable scheme to break your Bitcoin stash. They’re trying to go after the crowd in general because the best attack is the one you can pull off remotely without ever having to physically be there from another country. If someone’s breaking into your house because they have one of your keys and they need the second key, that’s a much more dangerous situation for them. Still possible, you should not tell people where you keep your Bitcoin and maybe you should try to have some privacy and maybe you should have an alarm or guns or something. But that’s a different class of attack than someone saying “Hey, I can introduce some malware into this and just steal tens of millions of dollars.” That’s really tempting to a hacker who doesn’t have any physical knowledge or skills or wants to be on the ground. That’s an entirely different risk profile.

SL: The other component is if there is any software that is potentially common between the different hardware wallets. Is that the case or, in your experience is it mostly segregated?

MF: That’s terrifying because there’s a lot of copy, paste of code. Crypto is just really, really hard. If you have a library that does something in your language, you’re likely to borrow from it heavily. Unfortunately almost all the hardware wallets are written in Python and MicroPython. That is not ideal but I think that’s a more minor thing. Again you can chase the perfect secure system that was written in three different languages. Every single receive address I’ve generated, I’ve verified in two different programming languages. I just don’t want to have any doubt that I have the private key for that address. But that’s probably not very mainstream to do. One day I hope we have so many hardware wallets that you could just pick “Hey I want one with two different languages” and you can still have five different choices of great products. But right now that’s not the world we live in.

SL: Just on the topic of that interaction between software and hardware, my understanding is it might be possible that the software is fine but there’s a problem with the hardware. The hardware is not doing what you think it is. If you think of the different stacks, the hardware and the software, and you’re thinking you’re safe at this upper level, but actually you’ve been pwned at the hardware level. That’s a scenario as well right?

MF: Yeah that’s one of the very difficult things. If they’ve written their code defensively every bit doesn’t trust every other bit. For example, in the beginning we used to just trust `/dev/random` which is the source of randomness on a computer, for our randomness. That was what SecureRandom was supposed to be using. Later we learned you can do deterministic k values in your signatures that look random or outwardly appear to be random but don’t rely on the random number generator. For example, on a signature you can write your software to avoid the risk of a bad hardware random number generator. That’s true in signatures. In generating private keys you need a source of randomness. Now some hardware wallets will have cool features where you can input your own randomness because randomness is also additive. You can XOR bytes where you basically add randomness to a random number generator and that’s only additive. It can’t hurt. In my very short bcwallet, a BlockCypher command line only wallet that again I don’t recommend using but it’s good for learning purposes, it’s not supported, it’s from 2016. But in that I ask you to bang on the keyboard because I say “I’ll assume that the random number generator that your computer uses is compromised so bang on the keyboard and feed me extra entropy. I’ll combine that randomness with my hardware’s randomness and hopefully even if I have bad hardware my software can overcome it. In theory there’s clever tricks you can do. Another common one, I believe Coldcard supports this, you can roll dice. You can even do that deterministically although you’re going to have to roll a lot of dice, so that’s very tiring or a pain in the butt. If you’re going to receive a lot of Bitcoin maybe you should buy a couple of dollars worth of dice and sit there and roll them. That’s another clever thing you can do. There are all these ways that your hardware and software interact. Even your hardware in your hardware, you might have in a hardware wallet a microcontroller unit, a MCU, and a secure element. If your MCU can tell your secure element what to do then your secure element is not really adding any security because your insecure microcontroller unit can control it. It is like a wormhole that you go down that is so hard. Again the solution is two signatures from two different devices. To point out this additive nature, if I were holding a really large amount of Bitcoin and I didn’t want to deal with the complexity of multisig, I don’t want to have an extra thing that I’ve got to back up and remember and tell my family where it is if something happens to me, but I just want to make sure my software works, I would do 2-of-2. For that second signature, I would use a key that’s not very secure. I’d leave it on my desk with a big flag that says “2-of-2 key here.” It would be a mnemonic without a password. Maybe it’d even be a shorter mnemonic than the full length. Or not, you should probably just use the full 2 word length. I’d have lots of copies of it, a copy at home and a copy at work and a copy with my family and a copy in a safe deposit box because that’s only one of the keys in a 2-of-2. I would use that for my second signature in addition to my first signature. Even though we’d say “Hey, that was really insecure, it’s just sitting on your desk in plaintext and you’re not guarding it very well” it is more secure to add a second signature with 2-of-2 than it is to just have one really secure signature with 1-of-1. If you can take your 1-of-1 setup and you’re guarding that one with your life because it is your Bitcoin and add a second one that’s insecure, you’ve improved your setup which is a very weird counterintuitive thing. To think “I’m going to behave really insecurely and I’m going to add security.” I’m not saying you should behave insecurely but if you were on the fence about multisig, add insecure multisig and you will be better off because again your attacker now has to compromise two independent systems simultaneously.

# Air gaps

SL: Another topic is air gapping. There are different ways to achieve this. I know Coldcard offers this as an option with a micro SD card where essentially you can use that to ferry unsigned or signed transactions between your internet connected computer and your hardware device. Can you talk a little bit to this idea of air gapping? Why is it important? How does it help?

MF: When you’re connected to the internet we call this a hot machine. When you’re disconnected from the internet we call this a cold machine. Your laptop may live somewhere in the middle because it’s probably connected to the internet most of the time but you can unplug it very easily, you do on flights and stuff. A hot machine is really dangerous because it might receive updates automatically in the software. Perhaps an attacker compromises one of the distribution systems for that service. Imagine a rogue employee at a hardware wallet or a software wallet compromises their GitHub account or however they’re releasing their software. And releases compromised software which would be something they’d be very able to do. Then they’d be able to say “Oh my God a third party did it. I had nothing to do with that, that wasn’t me.” If they were able to do that and your computer is connected to the internet and it just automatically downloads and installs these updates you’ve basically been pwned without even doing anything. The air gap is the absolute first line and most important defense. You have to use a good air gap because if your computer is one that’s say eternally quarantined, never connected to the internet, lives in your house and you installed the software once. That one time you installed it, you verified it in the best ways that you know how, PGP signature for example. Or downloading it on a clean machine first then it doesn’t matter what happens to that supply chain for their software in the future because yours is disconnected from the internet. That air gap is really good. There’s a reason why nuclear reactors run an air gap. They don’t want somebody clicking on an attachment in some email, installing a virus and messing with a nuclear reactor. That seems pretty good. We all like that system but even that air gap is vulnerable. The most famous attack is the 2010 Stuxnet from the U.S government to jump the Iranian nuclear reactor. This is just like straight out of a James Bond spy movie. They put basically some malware in USB drives, millions of them, that when it connected to most computers didn’t do anything so people didn’t notice it but when it connected to the exact computers that were known to be running in that system, both the hardware and the software, then it distributed its malware. It’s considered to have set back the Iranian nuclear program substantially. It worked. We jumped their air gap with USB drives. But if that technology is out there and the government can do it to people, individuals could come up with USB drives that could jump air gaps too. Coldcard’s SD card air gap is unfortunately currently the best off the shelf air gap product we have. I’ve played around with some prototypes of some new hardware wallets that are coming on the market. They use QR code air gaps and I can’t wait for these companies to launch because they’re so awesome. Right now if you want a proper air gap with a QR code you pretty much have to use Electrum or build your own. That’s a not ideal thing. You’re picking up a laptop upside down and trying to get it to read a QR code off another laptop. It’s just clearly not the best user interface but a QR code would be very hard to remotely pass code with an exploit. Whereas an SD card would be possible though very unlikely. The worst would be just plugging the hardware wallet into your hot machine. Again we assume it to be malware infected. That’s the reason we use the hardware wallet. We’re not using it for its great screen or keyboard or slow processor, we use the hardware wallet because it’s air gapped and then we plug it directly into our malware infected machine. The current setup is really not ideal. QR codes are great and you can use an SD card. It scares me, if it was your only signature I would be very uncomfortable with that. But if you have a multisig then for one of them perhaps I could see the value in that. One thing to keep in mind when you’re doing this air gap is that you can treat the host machine as completely malware infected. That’s ok because the air gap is designed to be quarantined and safe. If you were passing data from a malware infected machine to an air gapped hardware wallet via a QR code there’s not really a danger there. There’s not a thing that it can do to your offline machine. Now you shouldn’t have a malware infected machine but we probably all do. So if you can focus your security on your air gapped private key management solution, whatever that is, your hardware wallet or your build your own setup, you can focus all your security there and then the rest of it you can be pretty casual about. That’s the good usability security trade off. You want to really focus on your secure part and not focus so much on your hot machine because it’s probably compromised anyway. Obviously you want to do everything if you can but the ultimate would be just guard your keys with your life. Don’t worry about your laptop and whether you click the link in an email, you shouldn’t do that, but if you did your keys would be offline.

# PSBT

BIP 174: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki

SL: While we’re on this topic we’ve also got to touch on PSBT, Partially Signed Bitcoin Transactions. Michael, can you tell us why is that relevant here and what does PSBT help us with?

MF: PSBT is also known as BIP 174 and it’s just a standard way to pass around unsigned Bitcoin transactions. On its face it’s not that exciting. It’s just an encoding and a standard format for how we pass around “This is a 2-of-3.” Perhaps “Here is the derivation path for you to find this address.” Hardware wallets don’t store any real data on them typically. They’re stateless. You might have a seed and from that all your private keys are derived, but finding your private key is actually difficult because that one seed can generate billions of keys. If I want to find the key to transact with this UTXO I don’t want to try every single combination. I want to know where in the tree do I traverse to find that key. One of the nice things of many in PSBT or BIP 174 is a standard instruction set saying “Hey, using your extended public key here’s the derivation path to find your private key.” Now you have a seed that can derive private keys so you can follow that path. You can derive the private key very, very quickly. We’re talking on the order of 50-100 milliseconds. Your host machine which again could be completely malware infected, gives these instructions to your hardware wallet for it to verify “Yes I’ve got an address there. Yes this is what the transaction looks like. Yes this format makes sense. This is what the fee is. This change address belongs to me. I can calculate the sum of the inputs and the outputs and the change and figure out how much am I spending.” I can just show that to the user really easily because we think of Bitcoin transactions as “I’m sending one Bitcoin from me to you” but in reality I might have 10 inputs and 2 outputs. To a human trying to figure out “What’s the sum of the outputs minus the sum of the inputs? What are the ones I control versus the ones that I don’t?” you’re very quickly not able to keep that in your head. If I can have a standard format for relaying this to my hardware wallet, that my hardware wallet can understand and verify trustlessly, then my hardware wallet can just display to me “Hey. Here’s the transaction to sign, 1 Bitcoin spending to address A.” All I got to do is make sure A really is yours, that’s very easy and just click Yes. Maybe it’s a 2-of-2 or a 2-of-3 or a 2-of-5 or whatever my threshold is. It can say that too. “Hey this is a 2-of-5 and you’re one of them.” I will say there is one negative here, a slight asterix that I assume will be improved in future. There is a new attack which is let’s say I’m 2-of-2 and I pull up my hardware wallet and it says “You’re one of the two keys required”. How do I know what the other one of the two is? One of the risks is that the other one is actually my attacker. I send funds to a 2-of-2 address and I have one of the keys but so does my attacker. We don’t know that this has ever happened in the wild. When the attacker sees that on the blockchain they say “Aha. I have your money hostage. If you would like it back, I’m very generous. I’ll split it with you” or some other prisoner’s dilemma, game theory amount that they’re going to share with you in order to refund it. That would be a scary thing. Now some wallets are better about this. Trezor will show you “Hey you’re one of two and I have one.” Ledger just says “Good luck. Trust your malware infected machine.” This is kind of insane. I really hope they fix that. That seems like a very dumb stance they’re taking. There is that new thing, when you have multisig that’s the one new negative you introduce, but the UI will get there on that and you can verify that that’s really yours. I think that will get better in the future.

SL: As you said you want to use the address that it shows you on the hardware device not the one that’s on your computer. One of the difficulties right now is that at least the earlier hardware wallets have a very small screen. They don’t necessarily have the space to show you all those details. Hopefully, with newer wallets and newer products …I know Crypto Advance’s Stepan Snigirev, one of my previous guests, was talking about this idea of having a bigger screen that can show you all the details and show you exactly “These inputs, these outputs, 2-of-2”. All those details so that the user knows they can see on the hardware device, the one that’s doing the signing, what am I signing here?

MF: Yeah I’m excited for some of the products. I’ve seen some of their prototypes and Stepan is very smart. That was an enjoyable episode you did with him. He has some great talks on some of the vulnerabilities and hardware wallets that I recommend and that I’ve tweeted before. We could put them in the show notes. You want a screen big enough to verify. The reality is you don’t need a massive screen just for transaction verifying because it’s enough to say one Bitcoin to address X, fee is Y. If you supply enough information, and PSBT is a great format to supply information to your hardware wallet, then it can verify everything else. That’s pretty good. The amount of what you can verify is tricky. For example, if you’re signing a SegWit transaction then you sign the input values. You can verify the inputs and all the outputs are in the transaction and so you can verify the fee. If you’re signing a pre-SegWit transaction, the only way to verify the input values is to look them up in the blockchain. Some wallets will supply a proof saying “Here’s what you’re signing.” Some of them will say “It is actually hard because it’s just a lot of data.” Imagine you’re signing an input that was the output of a coinbase transaction. That transaction was paying out to mining pools so it had 1,000 recipients. We have to show you this transaction of 1,000 recipients to show you what your previous output was that you’re signing. It just becomes impractical and any answer is like “You should use a SegWit wallet if you’re going to use a hardware wallet because that’s better.” Because SegWit in BIP 143 changes the serialization format, so that the input that you sign includes both what you’re signing and a redundant copy of its value. The hardware wallet can check and say “Hey. How many Bitcoin is in this input that I’m signing?” The network would reject it otherwise. There’s all these clever things in SegWit that most people don’t know about because it’s got really weird marketing. They think it was whatever Roger Ver told them it was. They don’t know things like SegWit fixes transaction malleability and allows hardware wallets to sign inputs more accurately and it’s a block size increase. But anyway, a huge divergence. The point being that, hardware wallets, you want them to verify everything they can. The screen helps you with some of that but a lot of it’s buried in implementation details. It doesn’t matter how big your screen is if you don’t verify what change address is yours versus an attacker’s. Then you really don’t know what’s going on. If you don’t verify the inputs and the outputs then you don’t know the fee. This is where there’s just so much devil in the details that honestly no one wallet does perfectly. Two wallets is your answer because then you’ve got to trick both of them. Even if one doesn’t do it perfectly, the other hopefully won’t have that exact same vulnerability.

# Mnemnonics and passphrases

SL: Let’s talk about mnemonics and passphrases. I think users will have an experience where when they initialize that wallet they write down the 24 word seed. Maybe they make a passphrase. They might have a PIN for the device as well. I suppose some of the difficulties that the user might face is if they need to recover that wallet and they don’t want to obviously enter their seed onto the internet, hot computer because again that computer could have malware on it. Can you talk to some of the difficulties there and what does good look like?

MF: Your mnemonic is your Bitcoin. Owning Bitcoin is owning a private key that controls at least one UTXO but a mnemonic enables us to have an HD wallet with a collection of many private keys. Before we had HD wallets we had key pools and these were a disaster. A key pool is like “I’ll just generate 100 addresses with 100 private keys, I’ll back them up and I’ll transact with them. As I do more transactions I’ll generate more addresses.” The problem is if on day one I create 100 addresses and I create a backup, I store it really securely, I encrypt it, I put it in a safety deposit box, I give it to my lawyer and my loved ones and then I do 101 transactions. Now my backup is out of date. Now I need to go back and redo my backup. The solution to that was HD wallets which is excellent. Every wallet should be HD. Thankfully they all are now. The problem with that is how do I remember my extended private key or xpriv? It’s really long, it’s 512 bits. You’re not going to remember it. But a mnemonic, 24 words, that can be deterministically mapped to your extended private key, that’s memorizable. What we have now, the core thing that almost every wallet uses is this mnemonic. It’s typically 24 words although you can do shorter but unless you know what you’re doing don’t consider that option. Stick with the regular size if you don’t understand what those trade-offs are. You’ve got these 24 words and then you can add a passphrase optionally. What’s really cool about this passphrase is that it gives you some plausible deniability. Somebody holds a gun to your head and says “Ok type your password in” and you’d say “Ok 12345. There’s 1 Bitcoin in there and you’ve got my Bitcoin.” But maybe if you typed in 678910 there’s 10 Bitcoin there and you have another password and maybe another and another. This is a very neat feature. The implementation of it is clever. I do think it’s a little too James Bond. The classic story behind these types of attacks is that somebody beats you with a 5 dollar wrench until you talk. If you have a scheme where it involves you holding out that attack good luck. I forget which famous boxer it was that said “Everyone has a plan until they get punched in the face.”

SL: Mike Tyson.

MF: Yeah. That’s a neat thing, the passphrase. The passphrase is really valuable again to protect you against bad hardware or software. Imagine for example that your secure element, which in some of these instances might be guarded behind a PIN, was storing your passphrase. That’s one mechanism. The other mechanism is that you don’t have a secure element like the Trezor and the whole idea is that you don’t want to store the passphrase. If an attacker gets a physical access to your Trezor they need to type in your passphrase. That’s very neat. That’s one way to do it. It sort of makes it so that you can have this thing lying around and you don’t have to type in your 24 words all the time but still if somebody got it they need to type in a passphrase. I do highly recommend passphrases for their added security there. Making it something you have, your Trezor, and something you know. But I think that deniability feature is probably more James Bond than it is useful. You should probably have one passphrase that you remember instead of 10 different ones that you have with your…

SL: Decoy amount.

MF: You’re probably just going to forget.

SL: It’s similar to that security, usability trade off. The more separate passphrases you set up the more you’ve got to keep that backed up somewhere. You’ve got to have your family who know that and then they’ve got to know both your decoy one and your real one. You might have multiple setups. The complexity just massively amplifies.

MF: As the saying goes, complexity is the enemy of security. I was very reluctant to come to supporting multisig because it adds some complexity and I don’t like that. If you’ve got an application that stores trivial amounts of Bitcoin you might say “I just don’t care if 0.01 percent of the time I lose my money on it because it’s doing lots of transactions and that’s fine.” The reality is Bitcoin is more typically used to store value and so it’s a significant value that you care about. That probably is not your use case and if it were you might be more likely to be using Lightning. Probably for secure cold storage you do want multisig. The other thing that historically was a negative with multisig was that you have two signatures. That massively increased the size in bytes of your transaction and miners charge a fee per byte. Your transaction fees were higher with multisig which was an unfortunate penalty of the reality of the system. With SegWit another change we got was the witness discount. The witness or signature data is discounted in the miner’s calculation of whether or not to include your transaction. The reason for that maybe is outside the scope of this but it has to do with the incentives for running a full node. That’s a really cool thing. Now you can take advantage of this multisig without paying higher fees for it if you use a SegWit enabled wallet.

# Testing backups

SL: We spoke a bit to this idea of mnemonics and passphrases. I suppose another common thing a user might want to do is test their backup. They might want to pretend “I’ve lost Trezor, I’ve lost my Coldcard. Can I recover using my 24 words seed and my passphrase?” But the difficulty is I don’t want to necessarily put that in on my computer because it might have malware. It might steal my 24 word seed. Do you have any recommendations to think about there?

MF: I would say before you do any real transactions do testnet on your hardware wallet and do a dry run where you say “Hey this could totally be malware infected. If somebody gets my free testnet coins good for them. I’ll know that my system is insecure and it didn’t even cost me anything.” You can do a dry run where you don’t have to worry about this stuff. Because when it’s real money each thing you do, you’re double and triple checking. “Did I do this right? Is this the right step? Why is it asking me for this? What does this wording mean?” When you’re just doing it on testnet with coins that literally, have no value you can go really fast. You can try it four times. You can try it different ways, “What happens if I type in a different passphrase? Is there a notification here? Why is it saying that? Let’s try multisig now.” Just try, try, try stuff on testnet. There’s no cost to it at all. With most of your devices, if you don’t have a secure element, it’s very easy to just wipe a Trezor. Create a mnemonic, write it down dangerously and insecurely, store it on your iPhone or Android, in the cloud if you want because it’s just going to be used for holding testnet coins. Wipe the device, send yourself some coins, see if you can get back onto the device, change the passphrase, see what happens, do it over and over again. Try with multisig, just experiment on testnet. I think it is really unfortunate that testnet support is so minimal because it’s such a valuable resource. Part of the argument with Bitcoin fees going up was that it’s really bad for Bitcoin’s usage because historically, people just use Bitcoin on mainnet and they didn’t care at all about the fees. They used it for stuff that didn’t need censorship resistance because it was just easy and available. Then they had some Bitcoin leftover because that was really, really simple and they got comfortable with it that way. The classic story is they bought drugs on Silk Road and they had some change in there. “This is neat. How does this work? I’ve already done some transactions.” Well the reality is you can get that same experience of doing transactions, seeing how it works, playing with it, breaking it all on testnet. Then when you go on mainnet you don’t need to do a lot of transactions and worry about fees. You just did 20 free transactions on testnet. Now you only need to do one on mainnet. Play with testnet. That’s really, really your best friend.

# Querying a third party service

SL: Let’s move on now to this idea of are we querying or polling against a third party service? Common examples, let’s say I just used the standard Trezor, well now Trezor knows my xpub. Or If I use the standard Ledger interface, again same sort of thing, Ledger knows my balances etc. Typically, the two main ideas that I know of here are using Electrum Personal Server or something similar like ElectrumX or Electrs which is I think a Rust version. Then there’s Bitcoin Core with hardware wallet interface (HWI). Do you want to just touch on some of those and what are the benefits there?

MF: There’s a privacy element from your personal privacy and then there’s the security element of “This IP address has a lot of Bitcoin” so you’ve just painted a target on your back that you may not have wanted. Also there’s a technical detail that is if a wallet is sending home the extended public key or xpub, not only can that be used to generate all of your addresses so very bad for privacy, but also there’s a known, I don’t want to say it’s a hack because it’s a by design thing from the beginning, but if I have your extended public key and I have any of your child private keys then I can derive all of your child private keys for that extended public key. That’s not really that scary because why should a third party ever have one of your child private keys? But you could imagine a scenario where somebody says like “Hey. You’re having some issue with your hardware wallet? Help me diagnose it. Go into your hardware wallet advanced settings and pull out a spent private key. Don’t worry it’s already spent funds. It’s not going to be used for anything. Or derive me a new one and just give it to me” and that would be enough. One of the scary parts of these services is that you’re querying a hardware wallet with your extended public key. I would assume they keep that information. Maybe their business model is to sell it to chain analysis. There could be people in the middle intercepting that information. Your extended public key could be out there. Now if a child private key were to leak, which again really shouldn’t happen, but were it to happen now all of your funds would be at risk. There is both a privacy and security reason why you don’t want to query a third party service. You mentioned that the two are Bitcoin Core and Electrum. Electrum, by default the two biggest operators that we are aware of, of Electrum servers are Chainalysis. At least rogue employees have said that and it would be crazy if they weren’t running Electrum servers because they’d be able to de-anonymize massive amounts of Bitcoin traffic for almost no money. If they’re not doing that they’re really bad at their job. And we assume Bread Wallet. Bread Wallet is built as an SPV client and at least used to run a lot of servers for that reason. You don’t have to sign up and create an account but the system always works because somebody is running them. That’s really scary. You’re just handing off your private info to somebody in the cloud and you don’t even know who they are. Now you can run an Electrum server yourself and you can run it for the good of mankind or you can run it just for yourself that you connect to privately, but that is a pain. You have to run a whole Bitcoin Core node. You have to run Electrum on top of that to index all the addresses and you have to do things like set up SSL certificates and stuff. You can do it in Docker now which makes it a lot easier. If you know what Docker is, then you probably can imagine that that would be a lot simpler. But it’s a lot. That’s one way to do it. It is the best UI right now for multi hardware wallet, multisig. You can use Electrum, you can use it on your malware infected hot machine and that’s okay. You can run your Bitcoin Core node or not, which obviously has negatives if you don’t, and you can do multi-hardware wallet, multisig today. The other option is Bitcoin Core. There’s this thing called [HWI](https://github.com/bitcoin-core/HWI) which is Hardware Wallet Interface. That’s a really cool project. You’ve had some [guests](https://stephanlivera.com/episode/46/) on the show for that in the past. What I really like about that is that you can get the benefits of Bitcoin Core, which is validating consensus rules, knowing that the Bitcoin you’ve sent is real, generating transactions in the best possible way. You’re doing it in the reference implementation, things like fee priority RBF or bump fee, how to randomize your change addresses, how to do coin control. You can get all of those best practice things of Bitcoin Core but you don’t have to rely on it for the security of your keys because that’s really a separate thing. You’re securing that whole machine and is a much more complicated task. That’s really cool. Right now it’s still I would say for hackers and tinkerers. It’s not there for mainstream adoption yet. I’m hoping that [BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) is really going to change this because BIP 174 gave us a standard for communication. That could be built on top of Bitcoin Core. Anything and every hardware wallet should adopt BIP 174. I’m hoping that the way this reaches the masses is actually through BIP 174 even though there’s nothing groundbreaking in BIP 174. It’s just a standard way that we communicate between these devices but now every hardware wallet should follow the standard instead of creating their own. Any that doesn’t follow the standard, I think at some point we’ll have to say “Hey this isn’t compatible with Bitcoin. This is just a s\*\*\*coin only wallet. You should have a Bitcoin wallet for your Bitcoin and you can use this for s\*\*\*coins.” I look forward to that day because I think they’ll all update real fast. It’s not that hard.

SL: That’s great. As part of this series I will also get [Andrew Chow](https://stephanlivera.com/episode/99/) on to talk about some of his work with HWI as well. Let’s move on to the next one. I think we’ve sort of touched on some of this earlier but this idea of not signing something that the user hasn’t verified and the difficulties of that in certain cases where let’s say the screen is not big enough. Confirming the change address, the hardware wallet has this master seed, the xpriv. From that it can generate the private keys for these different addresses. If you’re generating the transaction to send Bitcoin you want to make sure that the change is coming back and it’s an address in your control with a private key where you have that private key. Is that a correct way to summarize it?

MF: Yeah. This would be a really clever attack. I go to spend Bitcoin and I want to send 0.1 Bitcoin to you and then I send the change back to myself. My hot machine generates a transaction. Now remember my hot machine is malware infected and it sends 0.1 to you and the change back to me. Only the change isn’t going back to me, the change is going to my attacker. I look on the screen and I say “It’s only 0.1 Bitcoin, this looks correct. My stash is not ruined.” I click confirm and then I find that actually all the change went to my attacker. That’s really something that should not happen in any good hardware wallet implementation. I think all of them do check that except for Ledger. Ledger just says “Verify the outputs yourself” which is totally nutty. It really makes no sense. I don’t know what they’re thinking. I think part of their thing is that there is the concern of this m-of-n. This is a step back, a more complicated thing. Imagine that it’s a 2-of-2 and my wallet says that I’m one of the two but the other one of the two is actually my attacker and they can ransom my funds that way. Or let’s say it’s 2-of-3 and I’m one of the two but the other two are my attacker so they’re able to just steal all the funds. Ledger just says “That’s complicated, we’re just not going to deal with it.” For that reason they push the end user to verify the inputs and the outputs as opposed to using the tools that we have to verify the transaction. It’s very odd. I would strongly recommend until they upgrade their software don’t use Ledger for a multisig transaction, which really means just don’t use Ledger. This is really silly because if they just supported that it wouldn’t be necessarily great but it would be a comparable product.

SL: As part of this series I’m going to be interviewing some of the Ledger guys as well so I will try and touch on that in the interview for that.

MF: I don’t mean it to crap on them them, I want them to make a better product. I want to make them make the other guys make even better products. The original version of the Ledger, the HW1 didn’t have a screen. Can you imagine a hardware wallet without a screen? What’s the point? Your malware infected hot machine says “Do you want to send your Bitcoin to this address?” You click the button on your device with no screen and you hope that it does what your malware infected computer told it to do and that that was the right thing. Now we have screens. It’s totally different.

# Open source hardware

SL: We’re living in the future now. We’ve got screens on our hardware wallets. Are there any other things around hardware wallets? I think we’ve touched on a few ones. On this question of open source hardware. What are your thoughts there because there are slightly different philosophies amongst some of the well known hardware wallets? Trezor is well known for being an open source hardware, Coldcard are very much about being an open source hardware. Although Ledger are known for having a closed source secure element. What’s your view there?

MF: The holy grail would be an open source secure element. That’s what we all want. It doesn’t yet fully exist. The best reason I’ve heard is that it costs somewhere on the order of 10 to 20 million dollars and nobody has spent 10 to 20 million dollars to open source a secure element. I imagine if there was one then everyone would pile on. Maybe in the future we’ll look back and say “Oh my God can you believe that we used Bitcoin when there wasn’t open source secure elements?” You generally have either open source software running without a secure element on an off the shelf microcontroller unit or you have a secure element that really is supposed to be secure. That’s something that has some benefits. I will talk about what it does in a second but we can’t verify that it’s really running that or even see the code of how that thing works. That’s sort of the trade off. Again my answer to this question is if you’re ideological about this in either direction then by all means go with it but you could just get one of each and require a signature from each. Now your attacker has to break both and that sounds pretty good to me. I get a little afraid with secure elements that are not open source because anything that’s not open source is just a really juicy target for attack. You can say it’s doing one thing and then it turns out it’s doing another thing. To me that sounds trusting, but again I would happily use it as part of my multisig. That’s really the magic of multisig is that it’s only additive. You can have a good wallet and a bad wallet and you’re better off than just having a good wallet. You might not know which is the good one and the bad one. Next year we might find a vulnerability in one of these major hardware wallets. Something that we thought was great was not so great and something that we thought was bad was actually better. Being able to use multiple is really the future.

SL: That’s a good point. How about firmware in software and the review of that code as well? There’s this idea of eyes on the code and that if you’ve got more eyes on the code then that’s theoretically a little bit better because there’s more chance of some bug or malware being picked up.

MF: One of the cool things about Bitcoin in general is it’s the world’s largest bug bounty program. If there were malware in Bitcoin there’s a real incentive for somebody to exploit it. Malware is probably the wrong term, if there were a bug for the glory, for the money it is the world’s best target. The fact that that doesn’t happen tells us that it’s probably running pretty well. That should give us more peace of mind. Every year of Bitcoin’s existence we should say “This is even harder to hack.” In general, in a software wallet the more people that use it, the more eyeballs are on it, the more businesses build their infrastructure on top of it we can say “That’s probably safer.” If somebody releases a new hardware wallet tomorrow and we’d never heard of it I would be really skeptical to store my life savings on that. But this is where multisig changes the game. The additive power of a second signature or even a third, but really I think a second gets you most of the way there, is so massive that I would happily take a lousy second signature over my single key signature. I hope that’s the biggest message that your listeners will take home. If you have a wallet that doesn’t play nicely with other wallets, a security product that doesn’t accept easy improvements in security, to me that’s really a lousy product. I’m hoping that with BIP 174 everyone just adopts this and we look back in a year and we think “Wow that was insane that Bitcoin was once so dangerous.” That actually brings me to something that I wanted to talk about in the beginning and I didn’t get to. There’s a reason why this is so important. It’s easy to just nerd out on all the possible ways that there could be compromises or attacks or Bitcoin could be lost but what usually happens when we have conversations like this is people say “This sounds really hard. I’m just going to use Coinbase”. That’s terrible. The worst thing you should do is give up your Bitcoin to somebody else because at that point you don’t have Bitcoin anymore. You have Bitcoin IOUs. MtGox users found this out in a very hard lesson. Not your keys, not your Bitcoin. It is the most important lesson in Bitcoin. It’s so easy to get lost in “I don’t know how to run my own full node. I don’t understand this command line stuff. I don’t understand this part. I don’t understand that part”. But if we get to a world where no one actually owns Bitcoin, they just have Bitcoin IOUs and there’s weirdos like me who want to manage their own private keys, we’re really in for trouble in three major ways. The big one is custodial losses. It’s just going to keep happening. One of the things that’s strange about this is that super large holders counterintuitively have a diseconomy of scale when it comes to security. For your first 10 to 100 million dollars worth of cryptocurrency you have pretty strong incentives to store it well. If it’s going to cost you 10,000 dollars a year in hardware costs, if you have to hire fancy consultants or software engineers but you’re guarding 100 million dollars you’re going to be happy to spend a couple hundred thousand dollars a year to make sure you’re doing everything right to store it. But if you’re holding 5 billion dollars, we don’t know the exact amounts that some of these large trusted custodians are holding but during the highs of the bull market of 2018 those were numbers that were regularly thrown around for some of the big guys, you are such a target for attack. If someone’s able to steal just 1 percent of your 5 billion dollars supply that’s still 50 million dollars. You are going to be facing attacks at every single corner. Your employees are going to be getting ideas if they’re not already. They’re going to be getting bribe offers. In fact one of the crazy things about exchanges is that they try to trick their own employees, see if they’ll bite. They both phish their employees and they try to bribe their employees which shows how on it they are and that’s good that they’re doing that. But the target is just so, so big. That’s not the ultimate goal. I mean, if we look at gold originally, part of the reason that gold was co-opted was that you had these trusted third parties storing your gold and then that really changed the whole nature. Going back to the Roman Empire you could debase the gold, you could print coins that weren’t fully backed by gold and go fractional. But you also get this account freezing and reporting that we see in Coinbase or PayPal or even your bank. We don’t want Bitcoin turning into that so owning your own private keys is really huge. The last reason why controlling your own private keys is so important is the governance attacks. We saw this in SegWit2x where we had major players saying “We represent all of these holders of Bitcoin and we decide what their Bitcoin is. We’re going to support a new coin and we’re going to sell all their Bitcoin for SegWit2x.” They were able to say that because they did represent a substantial ownership of Bitcoin. That’s a really scary thing. Imagine in the future we have an ETF and that ETF controls double digit percentage of the Bitcoin supply. They say “Ok we want to change Bitcoin. We don’t like the 21 million supply. We don’t think it’s good for the mining economy. We’re going to change it and we’re going to sell all of our Bitcoin for the new mining coin”. What a world of pandemonium that would create. Maybe Bitcoin does fine because the private key holders and the full node operators say “That’s not my Bitcoin so I’m not going to transact on that. Good luck. I’ll buy your Bitcoin off you if you’re selling.” Maybe we weather that storm just fine but the lower the percentage of the economy that they are and the higher the percentage of the economy that we are, the less significant they are. This is not just an academic thing and this is not just for your own security although that’s why I think you’ll probably heed the advice, this really is good for the ecosystem as a whole.

SL: That’s very well articulated, it’s really well thought out there. Ultimately there does have to be enough people out there holding their own keys, running their own node. I think the other point you’re trying to make there is even if you’re not running your own node it’s better that you at least hold your own keys. That’s often the way I’ve thought of it as well. Rule one of Bitcoin as Andreas says, not your keys, not your coins. Rule two is, not your node, not your rules. I think the way we teach this, many of my listeners probably are more intermediate or advanced themselves, is baby step people through. You can’t take them straight from leaving their stuff on the exchange to now fully running your own node. You’ve got to say “What’s one step further? Ok take it onto one hardware wallet. Now you’ve got one hardware wallet, let’s try to get you to a multisignature hardware wallet setup. Now let’s get you running a node.” I guess that’s the progression that we want to try to get people to come down that pathway.

MF: That’s exactly the path and the beauty is they’ll do it themselves. I get calls at each step of this on the way. The typical path I’m used to is someone’s on the order page on a Coinbase or now a Square Cash and they’ll say “I’m going to put my account routing or my debit card and PIN number into this site. Is this a scam?” I say “Well it depends how you define that. You’re probably going to get your Bitcoin. It’s probably going to be ok.” Then they say “Hey, I’ve got like 10,000 dollars on this site. It seems kind of sketchy. Should I store it myself?” I’m like “Absolutely, yeah. Here’s all these different ways you can do it.” Then they run a hardware wallet and maybe Bitcoin’s price has gone up in this time. They say “Hey. This hardware wallet knows about all my transactions.” I say “Yeah, it does. It’s not ideal. You should probably run it with your own full node.” Now, we’re also getting “And you should have a second signature.” People just do this naturally because they’re not idiots so that part’s neat. We don’t have to get them to do everything to be better than doing nothing.

SL: I agree with you but it maybe that it’s a selection bias. The proactive ones are the ones who do come and ask you. The non-productive ones are the ones who are just leaving it on the exchange.

MF: Yeah. I’m just telling you about the people I hear about and behind the scenes Coinbase is rumored to be storing just an obscene amount of cryptocurrency.

# 10x Security Bitcoin Guide

https://btcguide.github.io/

SL: It’s a challenging problem but I guess it’s all about how do you make it easy for people and how do you give them the info that they need? You’ve got a really great website now with this https://btcguide.github.io. I’ll put the link in the show notes. Michael tell us a little bit about what you’re trying to achieve here.

MF: It’s kind of silly. It’s just something I’m super passionate about. I’ve wanted a good hardware wallet for so many years and I can’t believe we’re 10 years in and I still think everything is pretty mediocre. Personally if I were going to have to recommend one I would say get the Coldcard. They’re the least bad but it’s not something that your mum would really say “Hey, this worked out great for me.” You have to be a little tech savvy to use it and I don’t love the SD card situation but it works. I discovered it through this process. I played with it before but I hadn’t gotten into details. I started a tweet storm about how I was frustrated with hardware wallets not having these key things that you need in a security product. Multisig support, an air gap, the ability for users to input stuff and for it to run trustlessly and verify what’s happening and some privacy mechanism where you could fetch your own Bitcoin data from your own full node. Those were not really crazy requests in a device that only exists for that purpose. Everyone chimed in “Well, you didn’t talk about my wallet. My wallet is actually good.” I was like “Well, it’s more nuanced. Your wallet has some good things but your wallet has some really gaping bad things.” I just started responding to all those things. All the info is in tweetstorms and sub tweetstorms and responses but it’s very hard for it to be organized. I created this silly comparison site. I should probably buy a domain name for it. It gives star ratings for each of those criteria to each of the main hardware wallets. Multisig support, air gap, user input, privacy and trustlessness are all rated for all the wallets that you could even potentially really use like KeepKey, Ledger, Trezor and Coldcard. Now there are other hardware wallets. You’ll get requests from people saying “Hey you didn’t mention John McAfee’s unhackable Android phone wallet.” It would rate so low. I listed why some are excluded. It is amazing to see what people are focusing on. There’s this not very well heard of wallet called Cobo Vault that has a beautiful QR code but it’s really made as a s\*\*\*coin wallet and it doesn’t seem to have much Bitcoin support and they’re just not compatible with multisig with other hardware wallets. It’s not even difficult. They just don’t do it. If they did I wouldn’t mind their s\*\*\*coining. It would be only additive and they have a beautiful QR code. It’s really expensive. It’s like a 500 dollar wallet but it seems great. Well I don’t want to be publicly on record saying it seems great. The QR code and screen are awesome and nobody’s doing that right now. It’s really weird to look at all the different products that are out there. People have these ones that are like they’re killer features that they’re the size of a credit card. I’m talking about the CoolWallet S. You’re like “Yeah but I just care about security. I don’t care about it’s form factor, that it looks like a credit card.” They’re all laid out in terms of their ratings on each of those things, detail if you mouse over you can see why and some Q&A about this stuff that breaks down a lot of what we’re talking about. My goal for this is I just want people to build better hardware wallets. I want to make those ratings much harder to get. I want it to be standard that you cannot be a hardware wallet that doesn’t support multisig through Bitcoin Core with your competitors. That seems insane to me. You’ve got to have a decent air gap and that should be like an SD card at the minimum which right now only one of them supports. You’ve got to have a way for your users to input their seed and mnemonic. The KeepKey has one button, that’s crazy. The Ledger has two that are very difficult to use. If you’re actually entering something, you’re going to go nuts so you’re not going to enter it. Then you’re going to forget what it is so that should be a really standard thing. From a privacy perspective they should all just connect to Bitcoin Core via BIP 174. There’s no reason to make a hardware wallet that isn’t directly compatible with Bitcoin. Now to be fair BIP 174 is only, depending on how you count, a yearish old. We’ve got to give these things time but the second there’s two of them onboard I’m going to shame everybody else and their scores are all going to go down. I know of two new hardware wallets that are in the works that are supporting BIP 174 natively at launch. They say there are a couple of months away, who knows, hardware’s really hard. Maybe they’re longer, but I can’t wait for that to happen. I think in a year we’re going to look back and we’re just going to say “We had it rough for so long and now it’s good.”

SL: Yeah that’s great. I particularly like how you can mouse over the stars and you’ve got a bit of an explanation about why. I think for a newbie who’s trying to think “Ok what are these hardware wallets, why did it get rated that way?” that’s an important factor. I think it is important to have some level of curation. I’m sure there’s probably dozens of hardware wallets but ultimately you’ve just got to put the ones that are well known and that people are at least somewhat familiar with. Are there any other points that you wanted to touch on with hardware wallets? There’s a lot we can go into. It might be nice to touch on a few of these other points. There is that chosen nonce attack. I thought it might be interesting to talk about that as well.

# Chosen nonce attack

MF: If any wallet implements a defense for a chosen nonce attack, if you’re doing single key signature, it becomes the must have hardware wallet. We’ve talked about randomness and hardware number generators a bit. It is just a reality of ECDSA. ECDSA is the Elliptic Curve Digital Signature Algorithm, that’s what Bitcoin uses. You may have heard of RSA, that is a different asymmetric cryptography algorithm that stands for the initials of the three mathematicians, Rivest, Shamir and Adleman. That’s what’s used when you browse the internet and you have that lock. There you’re using RSA on a https website or SSL website. With ECDSA, we have this issue of randomness in our signatures that we see popping up time and time again. In a chosen nonce attack the attacker somehow chooses the nonce. That’s the number used only once in cryptography and that’s a source of randomness. The attacker chooses that randomness and from your signature they can reverse engineer your private key effortlessly. That’s terrifying. Right now we just don’t have a way to prove that your hardware wallet isn’t using an attacker’s nonce. There are published attacks of this that are very simple and straightforward. Actually, one by a former guest of yours, Stepan Snigirev, who’s a quantum physicist and a very sharp guy. The one thing I should say about this attack is that I have to see your signature and I have to have chosen your nonce. How am I seeing your signature? It’s probable that you broadcast it on the Bitcoin network in which case now I’m in a race to double spend you. In that sense it could be a weak attack but if I have malware infected your host machine and it’s communicating with your hardware wallet then maybe you just send me home the signature. Not the private key but from that I’m easily able to reverse your private key from your signature because I’ve chosen your nonce and compromised your hardware wallet.

SL: There’s a lot here. Just to clarify, the hacker in this case is able to reverse out. Are they reversing out an individual private key for one address or are they reversing out the xpriv, the master private key?

MF: In this case they’re reversing out an individual private key but assuming they’re able to do this they may be able to reverse your … They may have a copy of your extended public key and then from that, with your child private key, they could calculate everything. The severity of this attack, there’s different ways they could pull it off. In one situation you broadcast a transaction, they see it on the network, they know your nonce, they know your private key and they try to double spend it. They try to broadcast a competing transaction with a higher fee. But they’re already starting from a behind position. There’s a question of whether or not you used RBF in your original transaction. That one is not the best attack, but it’s really profitable. If you found a vulnerability in the nonce that was used in the signature of a specific hardware wallet then you just go for it. But once it was known that it was out there then people would say “Don’t use this hardware wallet anymore. You got to upgrade or change.” You’d probably have a limited window to try to get these in flight transactions. But if you also knew their xpub then you could from that child private key generate all their other child private keys. Then perhaps you could steal some of their funds that they have sitting around and that would be far worse. This is a complicated one. It’s a nuanced one. There are some defenses for the chosen nonce attack of various UX and computational difficulty. I expect we’ll see a defense for that in the future but for now the best defense is multi hardware wallet multisig. Because if you know everything about one hardware wallet that you could possibly know and you’ve completely pwned it but there’s two signatures required, that’s still ok. That’s the amazing one. We could go into details of any of these attacks that are all scary and obscure, maybe it what affect you or maybe it wouldn’t. But if you just have two hardware wallets and require two signatures and they’re from two different manufacturers, you are massively insulated.

# Importance of having a secure element

SL: Is a secure element required or is it just simply not as important as having multisig support?

MF: To me, multisig is an absolute must. If a hardware wallet is not designed to do multisig then it’s not a security product. I don’t care what other security features it has, they’re missing out on the lowest hanging fruit. Supporting multisig is not an expensive thing. It’s not a complicated thing. It’s somebody saying “Our business model is not to make a security product. Our business model is to lock you into our platform. Probably because we make the most money selling s\*\*\*coin trading because we support thousands of altcoins and you can trade them on our platform. We’ve got a built in integration perhaps with something like Shapeshift. We’ve got partnerships for you to buy Bitcoin through us and other coins.” That’s not a bad thing. If you want to do that, that’s your business, that’s your right. It’s not my interest but that’s totally fine. The problem is you’re just not selling a security product anymore and I only want a security product. One of the things that I actually like about the Coldcard is that they don’t support altcoins because complexity is the enemy of security and the more code your hardware wallet runs, the more things it’s doing, the more opportunities there are for some sort of bug or vulnerability. The simpler you keep it the better. That’s why I led with my open source command line wallet is the fewest lines of code of any Bitcoin wallet. I think that’s still true. It was the fewest lines of code by a tonne when it was released. I don’t think there’s one that’s near it. I think that’s really cool. It shows you exactly how it works. You can learn about what it’s doing. You can see if something is off more simply. It doesn’t mean that it’s guaranteed to be secure but I think that’s a real feature. I do like that about Coldcard but Trezor supports lots of altcoins and I’m fine with using them as well. But multisig really is the most important thing. A secure element, if there was an open source one I’d be all about it. There’s not an open source one so I think it’s neat but I don’t really feel strongly either way. Use both.

# Advice for end users

SL: For listeners who are trying to up their game in terms of security. Let’s say they wanted to try to run Bitcoin Core with hardware wallet interface back at home and have some multisignature hardware wallets set up and they’ve distributed them. Is that a good aim for them? What’s your thoughts there?

MF: I think right now for the security, usability trade off, if you want to do multi hardware wallet, multisig you should use Electrum. I don’t love that because Electrum has problems with privacy and enforcing consensus rules, but you can run your own Electrum server in addition. If you switch to the Electrum multi hardware wallet multisig, you’ll be better off than the hardware wallet’s standard app they give you where you have no privacy at all. You know they’re taking all your info and it seems very dangerous connected to your hot machine. If you switched to Electrum, Electrum supports an air gap very nicely so you can switch to an air gap system if you want. You don’t necessarily need to with multi hardware multisig but you can if you’re worried about it. I know many large holders, people that are doing eight figure transactions on Electrum air gaps. That’s great that they can do that. I would recommend doing Electrum for now. But soon I hope to be recommending PSBT, BIP 174 via your own Bitcoin Core node and I see some really cool stuff in the works for that. That’s a way better way to run Bitcoin Core because you don’t have to be paranoid about “Is this the real Bitcoin Core that I’m running? Is there some vulnerability in my operating system? How did I configure my firewall? Am I doing all this stuff right?” If your keys are on your hardware wallet and you’re running Bitcoin Core, your only risk is privacy and that you might be on the wrong consensus rules. These are not insignificant risks but they’re totally different than losing your money. Now you can first focus really, really carefully on not losing your money on your hardware wallet and then you can focus as carefully as you want to on your hot machine about which operating system do you want to run your Bitcoin Core on and what level of verification do you want to do? That’s great. People should be able to opt in to the most levels that they want to. But first and foremost secure their coins. Losses are just so, so bad for the ecosystem as a whole. Even though as a holder I do get a little pleasure out of losses, meaning there’s less Bitcoin in the world. But that’s not inviting for new people to come in to know that they could just lose everything even if their investment does well.

SL: It’s more about making it easy for people to secure their Bitcoins and then know that they’ve got not 100 percent security but at least reasonable for a normal person. Not like some billionaire with massive resources kind of person.

MF: One of the ways that we can think about this is in websites they do uptime with service level agreements or SLAs. The expression is chasing nines. It’s very easy to make something that’s up 99 percent of the time and it’s pretty doable to do 99.9 percent. 99.99 percent uptime, that you can achieve but that doesn’t just happen. You have to do some work. But if you want five nines you’ve got to be good. If you want six that’s like you only get a couple seconds of downtime. You can think of it with Bitcoin in the same way only it’s the opposite. It’s like “What are the odds I’m going to lose my money?” Maybe I’m comfortable with a 0.1 percent chance. Maybe it’s an amount of money where I say “Hey I’m going to do this much work and there’s a 0.1 percent chance”. But maybe I want it to be 0.01 or 0.001 or 0.0001. Then you’re really going to have to do each extra step. From a loss perspective Bitcoin Core is the last thing you need to worry about. It would be great if everyone ran their own Bitcoin Core node but from the perspective of losing your Bitcoin you want to focus on the hardware wallet side first and then the Bitcoin Core side second. I wish that my answer was that we’re there and that you can just run Bitcoin Core on a Raspberry Pi really, really easily and do multi hardware wallet multisig without any command line knowledge. I think we will be in a year but we’re not there today.

SL: That’s great. Thank you very much for that. Maybe we’ll just summarize it then for the listeners. I think probably the two main lessons, one is multisignature is additive so try and use it. Number two is use testnet, so that you can really be more comfortable with the transactions you’re doing.

# Shamir’s Secret Sharing scheme

How to Share a Secret (Shamir paper, 1979): http://web.mit.edu/6.857/OldStuff/Fall03/ref/Shamir-HowToShareASecret.pdf

How to Share a Secret, Infinitely (paper): https://eprint.iacr.org/2016/194.pdf

SLIP-39, Satoshi Labs Shamir’s Secret Sharing for Mnemonic Codes: https://github.com/satoshilabs/slips/blob/master/slip-0039.md

MF: Yeah. Test everything. Those transactions are free. The one thing that nobody’s using or very few people use that I think a lot of people should use is a free thing called Shamir’s Secret Sharing scheme. This is on top of and in addition to your hardware wallet and backup strategy. It’s a neat different thing that is kind of like multisig but it’s different. If we have time we could talk a little bit about Shamir’s Secret Sharing scheme. If not save it for another.

SL: Let’s do it. We might as well. Let’s cover it.

MF: Shamir’s Secret Sharing scheme comes from a 1979 [paper](http://web.mit.edu/6.857/OldStuff/Fall03/ref/Shamir-HowToShareASecret.pdf) by Adi Shamir. Again he’s the S in RSA. He’s one of these crypto OG bad asses we have that are surprisingly still around. Ralph Merkle is still around, the guy in Merkle tree. Adi Shamir published his 1979 paper called “How To Share a Secret”. It’s two pages long. You can read it and you can grok it pretty fast. The idea is that you can set a m-of-n threshold to break apart your secret and your secret could be a Bitcoin private key. It could be a passphrase general mnemonic. It could be a passphrase to say a USB drive that stores all of your secrets. It could be anything you want. You can divide this secret up into these pieces and if somebody gets m of these Shamir shares they can combine them to get your secret. But if they get m-1 they get nothing. It is strictly superior to any other secret dividing construction where people are like “I’m going to take my password and cut the paper in half. I’ll put half the password at home and half at work.” First of all if you lost either half you’re in trouble. You would rather have 2-of-5 than 2-of-2. Or 2-of-3 or 2-of-4. You could set your thresholds however you want. Also it’s not really perfectly secure because if you had one half of it…. Let’s say you had a 16 character passphrase or password and you have 8 characters in one place and 8 characters in another. If somebody finds just the 8 characters they could brute force the other 8. Whereas with neither of them they might not be able to brute force the 16. Assuming randomness in your key space, your mileage may vary in terms of the numbers you put in. But it’s a very clever and smart algorithm that people have been using on the periphery of Bitcoin for a long time. It is not commonplace. Here’s why it’s so useful. The question I always ask Bitcoiners “What happens to your Bitcoin if you get hit by a bus?” For most Bitcoiners it means their Bitcoin dies with them. That’s really sad, especially if you have a family and it shouldn’t be that way. The other thing that people do is they leave their Bitcoin laying around unencrypted. They have it in a safe at home or under their mattress or a safe deposit box buried in a treasure map, whatever it is that they do. But if anyone comes across that seed, if there’s no passphrase, they can steal your Bitcoin. You want to have lots of backups because your house could burn down or there could be a flood or that hard drive could fail or that piece of paper could rot. You want some backups, maybe a Cryptosteel or something like that, but that password you want to split it. The really smart way to split your password is Shamir’s Secret Sharing scheme. You could give that password out to a number of trusted family and friends. You could set whatever threshold you wanted, it could be 2-of-5, it could be 11-of-20 and you hand out these pieces to your passphrase. If you get hit by a bus, assuming all those other people weren’t also on the bus or at least a quorum of them weren’t on the bus, they can combine together and get your passphrase. Combined with the physical seed that you’ve kept in your safety deposit box or something like that, your Bitcoin can be recovered. I think that’s something we’re going to see a lot more adoption of in the future because historically Bitcoin has been owned by young men who think they’re invincible and will never die. They haven’t worried about it. Maybe it hasn’t been worth that much but yeah.

SL: How would you add that into your hardware wallet multisig stack. I know there are different…For example, Casa go with the seedless approach. For them, when they’ve got their 3-of-5 it’s actually three hardware wallets, one held on your mobile device and one held by Casa as their recovery key with no seed backup. But another approach as we’ve talked about today is this idea of having multisignature hardware wallets. Maybe you’d distribute it out. Say you wanted to roll your own 3-of-5 but then where would the Shamir’s Secret Sharing come into that?

MF: One of the things that is tricky in all of this is first of all we remember complexity is the enemy of security. Also somebody has got to deal with this and you’re not there to tell them anything. Somebody is opening up a safety deposit box and they’re like “Oh I’ve got this Cryptosteel thing. I don’t know what that is. I’ve got these other people who have told me they have these Shamir shares and what is the m-of-n on the Shamir shares and what is the m-of-n on the multisig? Unfortunately right now this is pretty messy. Trezor has a [SLIP](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) Satoshi Labs Improvement Proposal for Shamir’s Secret Sharing scheme implementing that in a standardized way for splitting a key. I would like to see something that’s like WIF, Wallet Input Format for private keys where there’s a serialization and you know what you’re looking at. You scan a WIF, you have a private key. Any wallet can import that and it knows what it’s working with. But with multisig and HD this gets very complicated. Let’s say I’m looking at a Shamir Share of an xpriv, a seed, for an HD wallet that’s 2-of-3, I’m looking at a 6-of-10 Shamir Share of a 2-of-3 multisig seed. Where am I in this? What do I need? Do I have all the info? Because the ultimate end goal would be to just have something standardized where you dumped it into something like Bitcoin Core and it said “I know how to read all this stuff. Here’s your money.” Right now it gets messy. It really does. Unfortunately it’s a feature that pushes us toward centralization because while Coinbase doesn’t advertise this, they are legally compelled to pass your Bitcoin onto your heirs. I don’t think it’s going to be an easy process if you have to go through that but I do know of one case where that’s happened and it worked. So that is neat but that’s not great. We should have better ways to do this. I know of one custody company that’s working on this and they might develop a new standard for this as part of it. They would have one of your keys and you would have two other keys and it’s 2-of-3. With a death certificate they could combine their one key with one remaining key and all you have to do is make sure your family has access to one remaining key. Maybe you could do that with something like a Shamir’s Secret Sharing scheme where you broke that up into parts and you gave it to a bunch of family members. Then if they conspired to steal your Bitcoin they could only get one of two necessary keys anyway. You could see a world like that where you give one to a lawyer or one to a custody agent and then you divide another one amongst your family and friends. It does create a weird thing. If you buy life insurance that beneficiary has an incentive to kill you. If you give out Shamir Shares to your fortune your friends have an incentive to kill you. So just pick people who wouldn’t kill you.

SL: Always good advice.

MF: And maybe make a high quorum so a lot of them need to be in on it.

SL: It is a bit complicated but I suppose it’s just a matter of people starting on that pathway. Right now there’s a lot of people who are just leaving it on an exchange. Those people can take one step further and that’s really where we’re going with this podcast. I think that’s pretty much all we’ve got to cover for this. There’s so many little rabbit holes we could go down. I’ll definitely be getting you back on the show again in future but just for now if you could just let the listeners know where they can find you, where they can follow you and keep up with what you’re writing.

MF: Yeah. I tweet and blog occasionally about Bitcoin. I’m /@mflaxman on Twitter. That’s probably the easiest way. You can also see my personal website which is michaelflaxman.com.

SL: Awesome. Thank you very much. This has been really educational. I’m sure my listeners will get a lot out of this one, so thank you.

MF: Thank you. Hopefully I’ve helped them more than confused them.