SLP97 Michael Flaxman – Every Bitcoin Hardware Wallet Sucks

Posted in: bitcoin Posted on

Michael Flaxman, Bitcoin Educator and Developer joins me in this episode (part of the SLP Hardware Wallet Interview series) to talk about the current state of Bitcoin Hardware Wallets. This episode is a must listen to learn the differences between some of the current popular Hardware Wallets, and give you a framework on how to think about Hardware Wallet security. This will help you think more clearly about how to secure your own bitcoins. 

We talk:

  • The current state of hardware wallets
  • Multi signature is additive
  • Why you should use Testnet
  • Secure elements
  • PSBT
  • Backups
  • Shamir’s secret sharing

Michael Flaxman links:

SLP Hardware Wallet Series link: https://stephanlivera.com/slp-hardware-wallet-interview-series/ 

Sponsor links:

Stephan Livera links:

Podcast Transcript Sponsored by GiveBitcoin.io:

Stephan Livera: Michael, welcome to the show.

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

Stephan Livera: Yeah, so 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 just give a bit of an intro on yourself?

Michael Flaxman: Sure. I fly under the radar and that works just fine for me, so I’m not looking to change anything. But, 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 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.

Michael Flaxman: 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, and 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. But then, yeah, I started building Bitcoin apps in 2013. I was a very minor contributor to Pycoin. In 2015, I wrote blockcypher’s, block explorer, which isn’t … I don’t think it’s really 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.

Michael Flaxman: Last time I looked at it was like eight figures page views per month, which was just wild, but it’s not something that I’m involved in and haven’t been for many years. In 2016, I wrote their command line wallet and 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. It’s 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. Now, every wall [crosstalk 00:02:09].

Stephan Livera: Yeah. That’s definitely ahead of its time.

Michael Flaxman: You really see like, 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, Bitcoin has been like, 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.

Stephan Livera: Fantastic. I know you are also recently helping Jimmy on his Programming Bitcoin course as well, as a teaching assistant, and you provide technical review and feedback as well.

Michael Flaxman: Yeah. I’ve known Jimmy since before he was, I guess, a crypto Guru. If that’s the great word. Before he was famous, 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. I met him as, 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 it’s like he is so gifted at that.

Michael Flaxman: It’s almost sad that neither he nor I are writing code full-time anymore. Yeah, 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, I don’t know, 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.

Stephan Livera: Excellent. Let’s get into our topic for today, which is around hardware wallets and why a lot of them are not secure, but there are certain mitigations, as I’m sure we’ll get into. But, let’s just talk a bit about some of the difficulties involved. Why is it so difficult to secure your Bitcoins?

Michael Flaxman: Yeah, yeah. 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.

Michael Flaxman: We’re talking around US$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, “Oh, years ago. I lost …” and the numbers could be 0.1 Bitcoin, but a number of people have come to me with a hundred Bitcoin losses and I’m just like, “Ouch. Ouch, that sucks.”

Michael Flaxman: 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, but, 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% chance you’re going to lose money.

Michael Flaxman: 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% or 0.1% of the time, you wouldn’t think like, “Well, 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, whatever, 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 leaving your homeland and this is your life savings, finding out that, oops 0.01% of time you lost all your money, that’s really, really not okay.

Michael Flaxman: It brings us to this weird place where if you told me to pay an extra 0.01% 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%, I’d pay it. But, unfortunately, if you’re the 0.01% of times that it happens, it 100% 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, if 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.”

Michael Flaxman: 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 values, 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, “Well, for 10%, I’m not going to touch it,” or whatever the number was. I mean, at some point it got much, much higher or at some point now it’s much lower. But, some people, it still wasn’t worth it to them, and that is really, really hard.

Michael Flaxman: 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 just that you should be cautious and paranoid, because it is really hard. One of my favorite examples is, there was a bug 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.

Michael Flaxman: It’s part of the proof in the ECDSA signature. If that bit is random, then it doesn’t matter. It’s not something that you ever would look at again. You can think of it as like 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.

Michael Flaxman: It’s the job, a library for randomness. It’s called secure random developers, who used it, were doing the right thing, and then, surprise, you lost your money. Those are the types of examples. Now, they’ve since fixed that, that was 2013. But even BitGo, which is a very reputable company, I’m not meaning to say anything negative about them, specifically, they had a recovery script, 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 have been open source for a long time, and somebody ran the script and lost 85 Bitcoin.

Stephan Livera: Ouch.

Michael Flaxman: This was in April 2015. To BitGo’s credit, they just 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.

Michael Flaxman: When planes take off and land, we don’t say like, “Well, there’s only a 0.1% 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.

Stephan Livera: There’re 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 a different code that, potentially, is malware.

Michael Flaxman: 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 ChainAnalysis. 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 recommendable to run your own Electrum server, which is a pain in the butt.

Michael Flaxman: But, when you connect to a server, it can connect to a server. It can send you any message at once. 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, to this day, persists in Electrum in a weird way and that now Electrum servers can’t send you that message on a new version of Electrum but 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.

Stephan Livera: Right, and in that example, now this is, again, I know some of my listeners, there are 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 be GPG verify right? They should be verifying the software release is signed by the private key of unknown developers. In this example, Thomas V, theoretically, should be checking that this upgrade signature matches that, but in practice, not many people do that.

Michael Flaxman: Exactly. This is where private key management gets really, really hard, because each thing that you say, “Hey, it’s probably fine. I downloaded it from the Electrum website,” and you want to be really sure, like, “Was it actually the Electric website or was it some impostor? 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.

Michael Flaxman: There’s a really strong incentive to do this. I mean, if you are a talented hacker and you’re not a white hat hacker, who works for companies securing them, but you want to be a black hat hacker who steals, there is no better use than cryptocurrency, because it used to be like, 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, I mean, it’s like 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.

Michael Flaxman: 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, and 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, so that’s a very common attack. But 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.

Michael Flaxman: At every step of the way, yeah, 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%, and 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%. The thing that we’re going to talk about in a bit, is multi-sig. The benefit of multi-sig is that, if you use two different hardware wallets, or two different setups and you require two signatures, and your numbers could be whatever you want.

Michael Flaxman: You could require three of five signatures, four of five, two of three, 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% of the time or maybe even 99.99% of the time with something like say a Trezor. Then, you can do the same with something like, say, a Coldcard and then you get this additive benefit of multi-sig, 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, is the amazing power of multi-sig.

Stephan Livera: Right. Yeah, yeah. I guess, let’s sort of talk through a few of the other ways, or common ways, that a hacker might try to compromise you. Another example might be if they had some malware that made you copy-paste the wrong address and paste their own receiving address. That’s probably another example.

Michael Flaxman: 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.”

Stephan Livera: On that, sorry, on that point, how difficult is it, computationally, to make, because I understand there was a little bit of … in the past people used, for example, vanity addresses, right?

Michael Flaxman: Mm-hmm (affirmative).

Stephan Livera: Andreas, famously, has one Andreas or something like that. It was more difficult to generate an address with specifically those characters you wanted, but then, 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?

Michael Flaxman: Yeah. The way Bitcoin address generation works is, behind the scenes, there’s the secret exponent. It’s a really large number between, roughly, one and two to the 256, which is unfathomably large. I mean, 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.

Michael Flaxman: It’s a really, really large amount of entropy, so 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 Base 58, or at least for a previous non-native SegWit addresses. You add a checksum you do all this stuff, 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.

Michael Flaxman: 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 like, “Can I get something that starts with this many digits, or,” 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.

Michael Flaxman: That’s why we have 1Andreas, but we don’t have 1AndreasAntonopoulos. That is, 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 nine-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 the first three of the first four digits were correct and three of the last four were correct, you’ll probably be fooled. It’s hard.

Stephan Livera: Yeah. That’s tough. Yeah, but it was good. Thank you for the explanation on that, because I think that is another common heuristic that people already are using.

Michael Flaxman: Yeah, and 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 you’d say like, “Wow, these eight digits match. That can’t possibly be a coincidence,” but maybe that’s just what they’re really good at, is making eight digits match, because they have every financial incentive to do it.

Stephan Livera: Yeah, that’s scary stuff. But yeah. I think, how about also the supply chain risk as well? That’s another big factor that people talk about.

Michael Flaxman: 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.

Michael Flaxman: 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, so 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, which 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 a hardware wallet A, B or C, where you know the private key.

Michael Flaxman: Then, once the number has gotten big enough, say you’re at over $100 million, 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, so it’s a scary world out there. The biggest thing is that, I do every tinfoil hat thing you can do, and I assume that what I do is not 100% safe. It’s multi-sig that I think really changes the whole nature of the equation.

Stephan Livera: I guess, let’s start talking through then, what does a good hardware wallet look like? I think a good place to start would be multi-signature support.

Michael Flaxman: Yes.

Stephan Livera: Let’s talk a little bit about, how does multi-signature help?

Michael Flaxman: When multi-sig originally came out, a lot of the use case was 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.

Michael Flaxman: 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, “Okay, 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.

Stephan Livera: They are, yes.

Michael Flaxman: They’re here in Austin, Texas. Maybe Unchained has a key, you have a key, and another custodian has a key. In a two-of-three situation, two of three of those entities would have to be hacked. That is true, and multi-sig can provide benefits for that. What I’m really excited about multi-sig for is that you get independent hardware and software stacks. Those signatures could come from two hardware wallets it’s sitting on your desk. But if one’s a Trezor and one’s a Coldcard, a now an attacker has to attack the supply chains of both those companies.

Michael Flaxman: 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.

Stephan Livera: No, no, they’re fine. That’s good. The other component, I think, is 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, that 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 two of three scenario?

Michael Flaxman: Yeah. If you’re using … This is often called M of N, which is a threshold, you require M signatures of N total possible signatures, and that’s something that the user can configure. You could decide you want two of three. That’s probably the most common one that we see in the wild. You would say, “Okay, 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 pub keys that those wallets hold to sign. You have these three devices, and you want two of three of them to sign.

Michael Flaxman: 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, and 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 two of three 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.

Michael Flaxman: 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. I mean, that’s an entirely different risk profile.

Stephan Livera: Yeah. 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?

Michael Flaxman: Yeah. 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, we’re talking like, you can chase the perfect secure system that was written in three different languages.

Michael Flaxman: Every single time, every single receive address I’ve generated, I’ve verified in two different programming languages, because 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.

Stephan Livera: Just on the topic of that interaction between software and hardware, my understanding, and I’m sure you can help me understand this, 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. It’s like that idea of, if you think of the different stack, if you will, 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?

Michael Flaxman: Yea, that’s one of the very, 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 secure random was supposed to be using. Later, we learned like, “Hey, you can do deterministic K values in your signatures that look random,” or outwardly appear to be random, “but actually don’t rely on the random number generator.”

Michael Flaxman: There are, for example, on a signature, you can write your software to avoid the risk of a bad hardware random number generator. Now, that’s true in signatures. In generating private keys, you need a source of randomness. Now, some hardware wallets will have cool features on this where you could input your own randomness, because randomness is also additive. You can do, this thing is called XORing bytes, where you basically add randomness to a random number generator and that’s only additive. It can’t hurt, so in my very short BC wallet is a BlockCypher for command line-only wallet that, again, I don’t recommend using, but it’s good for learning purposes.

Michael Flaxman: It’s not supported. It’s from 2016. But in that I asked 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 and 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.

Stephan Livera: It does. Yeah.

Michael Flaxman: You can even do that deterministically, although you’re going to have to roll a lot of dice, so that’s very tiring or pain in the butt, but 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 and your hardware, because you might have in a hardware wallet, a Micro Controller Unit, an MCU, and a secure element.

Michael Flaxman: If your MCU can tell your secure element what to do, then your secure element is not really adding any security, because your un-secure Micro Controller Unit can control it. These things, it’s like a wormhole that you go down that is so, 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 multi-sig, I don’t want to have an extra thing that I 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 two of two.

Michael Flaxman: 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, “Two of two key here.” It would be a mnemonic without a password. Maybe it’d be an even shorter mnemonic than the full length or not. You should probably just use the full 24-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 two of two. I would use that for my second signature in addition to my first signature.

Michael Flaxman: Even though we’d say, “Hey, that was really insecure, it’s just sitting on your desk and plain text, and you’re not guarding it very well,” it’s more secure to add a second signature with two of two, than it is to just have one really secure signature with one of one. If you can take your one-of-one 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 counter intuitive thing to think, “Oh, 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 multi-sig, add insecure multi-sig, and you will be better off, because, again, your attacker now has to compromise two independent systems simultaneously.

Stephan Livera: Right. Another topic is air gapping. This is another one where, okay, 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?

Michael Flaxman: Yeah. 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, and you do on flights and stuff. A hot machine is really dangerous, because it might receive updates automatically in the software, so, perhaps, an attacker compromises one of the distribution systems for that service.

Michael Flaxman: 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, the 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’s connected to the internet, and it just automatically downloads and installs these updates, well, you’ve basically been pwned without even doing anything.

Michael Flaxman: 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, so 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.

Michael Flaxman: 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.

Stephan Livera: Wow.

Michael Flaxman: 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, so awesome.

Michael Flaxman: 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 weird, 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. Then, the worst would be just plugging the hardware wallet into your hot machine, which, again, we assume to be malware infected. That’s the reason we use the hardware wallet. We’re not using it for it’s 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.

Michael Flaxman: The current set up is really, 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 multi-sig then, for one of them, perhaps I could see the value in that. Also, 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 okay, 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.

Michael Flaxman: 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 you 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 or not focus so much on your hot machine, because it’s probably compromised anyway. Obviously, you might 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, which you shouldn’t do that, but if you did, your keys would be offline.

Stephan Livera: Right. Yeah. Look, while we’re on this topic, we’ve also got to, obviously, touch on PSBT, Partially Signed Bitcoin Transactions. Michael, can you tell us, why is that relevant here, and what does PSBT help us with?

Michael Flaxman: Yeah. 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, “Okay. This is a two of three. 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 if you have like … 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.

Michael Flaxman: 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 and you can derive the private key very, very quickly. We’re talking on the order of like 50-100 milliseconds. Your hardware wallet, which, again … or sorry, your host machine, which, again, could be completely malware infected, gives these instructions to your hardware wallet that are just for it to verify, “Yep, I’ve got an address there.

Michael Flaxman: “Yep, this is what the transaction looks like. Yeah, 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 two outputs. To a human trying to figure out, “Okay, what’s the sum of the outputs minus the sum of the inputs, and one of the ones I control versus the ones that I don’t,” you’re very quickly not able to keep that in your head.

Michael Flaxman: 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, one Bitcoin spending to address A.” All I got to do is make sure A really is yours, and that’s very easy and just click, yes. Maybe it’s a two of two, or a two of three, or two of five or whatever my threshold is, it can say that too, “Hey, this is a two of five 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, but there is a new attack, which is, let’s say I’m two of two, and I pull up my hardware wallet and it says, “Okay, you’re one of the two keys required,” how do I know what the other one of the two is?

Michael Flaxman: One of the risks is that the other one is actually my attacker. I send funds to a two of two address and I have one of the keys, 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. Well, 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 that one.”

Michael Flaxman: Ledger just says, “Good luck. Trust your malware-infected machine.”

[crosstalk 00:45:37]

, which is 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 multi-sig, 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.

Stephan Livera: Right. Part of that also is, if you’re trying to, 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, right?

Michael Flaxman: Mm-hmm (affirmative).

Stephan Livera: One of the difficulties right now is that some of the, or at least the earlier hardware wallets, to have a very small screen, they don’t necessarily have the space to show you all those details. Hopefully, with the new versions, with newer wallets and newer products … For example, I know Crypto Advance’s Stepan Snigerev, one of my previous guests who was talking about this idea of having a bigger screen that can show you all the details and show you exactly, “Okay. These inputs, these outputs two of two,” whatever, 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?

Michael Flaxman: 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 that I’ve tweeted before. We could put them in the show notes.

Stephan Livera: Sure.

Michael Flaxman: Yeah, 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, so you can verify the inputs and all the outputs are in the transaction, so you can verify the fee.

Michael Flaxman: 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’s 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.”

Michael Flaxman: Because SegWit in BIP 143 changes the serialization format, so that you sign … 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 they just think it was like, well, 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.

Stephan Livera: Sure. Sure.

Michael Flaxman: The point being that, hardware wallets, you want them to verify everything they can, and 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 got to trick both of them. Even if one doesn’t do it perfectly, the other, hopefully, won’t have that exact same vulnerability.

Stephan Livera: Yup. Okay. Let’s talk about mnemonics and passphrases now. 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, but then 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?

Michael Flaxman: Yeah. The really big thing is your mnemonic is your Bitcoin. Really 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, “Hey, I’ll just generate 100 addresses with 100 private keys, and I’ll back them up, and I’ll transact with them. As I do more transactions, I’ll generate more addresses.” Well, the problem is, if on day one I create 100 addresses and I create a backup, but I store it really securely, I encrypt it and I put it in a safe deposit box and I give it to my lawyer and my loved ones, and then I do 101 transactions, well, now my backup is out of date.

Michael Flaxman: 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 in mnemonic, 24 words, they 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, and you’ve got these 24 words and then you can add a passphrase optionally.

Michael Flaxman: What’s really cool about this passphrase is that it gives you some plausible deniability. Somebody holds a gun to your head and says, “Okay, type your password in,” you’d say, “Okay, one, two, three, four, five.” There’s one Bitcoin in there and, “Aha, you’ve got my Bitcoin,” but maybe if you typed in six, seven, eight, nine, 10, 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 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.”

Stephan Livera: Mike Tyson. Yeah.

Michael Flaxman: Yeah, so 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.

Michael Flaxman: 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-

Stephan Livera: Decoy amount.

Michael Flaxman: … covert identities. You’re probably just going to forget.

Stephan Livera: Right. In reality, that’s the other thing as well, because we … it’s similar to that security/usability trade off, the more separate passphrases you set up the more now 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.

Michael Flaxman: As the saying goes, complexity is the enemy of security. I was very reluctant to come to supporting multi-sig, 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 like, “Hey, I just don’t care if 0.01% of the time I lose my money on it, because it’s doing lots of transactions, and that’s fine.”

Michael Flaxman: The reality is, Bitcoin is more typically used to store value, and so, it’s the significant value that you care about, and that that’s probably not your use case and if it were, you might be more likely to be using Lightning. Probably for a secure cold storage, you do want multi-sig. The other thing that historically was a negative with multi-sig 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 multi-sig, which was an unfortunate penalty of the reality of the system.

Michael Flaxman: With SegWit, another change we got is there’s 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 if 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 multi-sig without paying higher fees for it if you use a SegWit-enabled wallet.

Stephan Livera: Yeah. All right.

Michael Flaxman: That’s pretty cool.

Stephan Livera: Yeah. We spoke a little bit to this idea of mnemonics and passphrases. I suppose another thing, another common thing a user might want to do is, say, test their backup.

Michael Flaxman: Yes.

Stephan Livera: Or they might want to say, pretend I’ve lost Trezor, I’ve lost my Coldcard, can I recover using my 24 words seed in 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 or things to think about there?

Michael Flaxman: I would say, before you do any real transactions, do testnet on your hardware wallet and do just 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 if 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. Like, “Did I do this right? Is this the right step? Why is it asking me for this? What does this wording mean?” But, 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.

Michael Flaxman: You can try it different ways, “Hey, what happens if I type in a different passphrase? Is there a notification here? Why is it saying that? Let’s try multi-sig 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 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.

Michael Flaxman: Try with multi-sig, just experiment on testnet. I think, this is a 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, so 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.

Michael Flaxman: The classic story is, they bought drugs on Silk Road and they had some change in there, like, “Oh, 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.

Stephan Livera: Okay, 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, et cetera.

Stephan Livera: 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. Do you want to just touch on some of those and, what are the benefits there?

Michael Flaxman: Yeah. There’s a privacy element from your personal privacy, and then there’s the security element that is, first of all, you said like, “Hey, 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.

Michael Flaxman: 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.

Michael Flaxman: 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, 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 Personal Server and that’s pretty much true. Or sorry, there’s Electrum and Bitcoin Core. Electrum, by default, the two biggest operators that we are aware of, of Electrum servers, are Chain Analysis, 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.

Michael Flaxman: If they’re not doing that, they’re really bad at their job. 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.

Michael Flaxman: You can do it in Docker now, 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, multi-sig. 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, multi-sig, today. The other option is Bitcoin Core and there’s this thing called HWI, which is Hardware Wallet Integration. That’s a really cool project. You’ve had some guests on the show for that in the past.

Michael Flaxman: 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. Then, you’re securing that whole machine and is a much more complicated task. That’s really, really cool. Right now it’s still, I would say, for hackers and tinkerers. It’s not there for mainstream adoption yet.

Michael Flaxman: I’m hoping that BIP 174 is really going to change this, because BIP 174 gave us a standard for communication, so 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 like, “Hey, this isn’t compatible with Bitcoin. This is just a shitcoin-only wallet. You should have a Bitcoin wallet for your Bitcoin and you can use this for shitcoins.” I look forward to that day, because, I think, they’ll all update real fast. It’s not that hard.

Stephan Livera: Yeah. Well, yeah, that’s great. As part of this series, I will also get Andrew Chow 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 a little bit earlier as well, but this idea of trustless, and not signing something that the user hasn’t verified. I think we were talking a little bit about that, around the difficulties of that in certain cases where, let’s say, the screen is not big enough.

Stephan Livera: Also, around confirming the change address, availability or, I guess, my understanding there is, in some sense what that is is, 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?

Michael Flaxman: Yeah. This would be a really clever attack, because 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 think, I look on the screen, and I say, “Well, 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.

Michael Flaxman: 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, more complicated thing. Imagine that it’s a two of two 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.

Michael Flaxman: Or, let’s say, it’s two of three 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 like, “Hey, 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 multi-sig transaction, which really means, just don’t use Ledger, which is really silly, because if they just supported that it wouldn’t be necessarily great, but it would be a comparable product.

Stephan Livera: Yeah, sure. Well, as part of this series, I’m actually going to be interviewing some of the Ledger guys as well, so I will try and touch on that in the interview for that. Yup, we’re understood there. Let’s talk about, all right, I guess-

Michael Flaxman: Oh, and 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 –

Stephan Livera: Oh, yeah. For sure. Same. Same.

Michael Flaxman: … version of the Ledger, the HW.1, didn’t have a screen. Can you imagine a hardware wallet without a screen? What’s the point? You just literally, 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.

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

Michael Flaxman: Yes. The Holy Grail would be an open-source, secure element. That’s what we all want. It doesn’t yet fully exist, because they’re just … The best reason I’ve heard is that it costs somewhere on the order of 10 to $20 million, and nobody has spent 10 to $20 million 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.

Michael Flaxman: That’s something that has some benefits, because 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, really juicy target for attack, because you can say it’s doing one thing and then it turns out it’s doing another thing.

Michael Flaxman: To me, that sounds trusting, but, again, I would happily use it as part of my multi-sig. That’s really the magic of multi-sig, 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, and 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, and 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.

Stephan Livera: Yeah. Yeah. No, that’s a good point. How about firmware in software and the review of that code as well? Because I think that’s another comment consideration, is that 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 kind of bug or malware being picked up.

Michael Flaxman: Yeah. I mean, 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. In fact, 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.

Michael Flaxman: We can say, “Hey, 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 multi-sig 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.

Michael Flaxman: 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, “Oh, this sounds really hard. I’m just going to use Coinbase,” and 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.

Michael Flaxman: Mt. Gox users found this out a very hard lesson. Not your keys, not your Bitcoin, it’s 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, counter-intuitively have a dis-economy of scale when it comes to security.

Michael Flaxman: For your first 10 to US$100 million worth of cryptocurrency, you have pretty strong incentives to store it well. If it’s going to cost you $10,000 a year in hardware costs, if you have to hire fancy consultants or software engineers, but you’re guarding a $100 million, 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, which 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. Because, if someone’s able to steal just 1% of your $5 billion supply, that’s still $500 million.

Michael Flaxman: I’m sorry, that’s still $50 million. 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 fish their employees and they try to bride 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 and 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.

Michael Flaxman: I mean, 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. Then, 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, “Hey, we represent all of these holders of Bitcoin and we decide what their Bitcoin is, and we’re going to support a new coin and we’re going to sell all their Bitcoin for SegWit2X.”

Michael Flaxman: They were able to say that, because they did represent a substantial ownership of Bitcoin and 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, and they say, “Okay, we want to change Bitcoin to … 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,” and what a world of pandemonium that we’ll create. Now, maybe Bitcoin does fine because the private key holders and the full node operators say, “Well, 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.”

Michael Flaxman: 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 hear the advice, this really is good for the ecosystem as a whole.

Stephan Livera: Yeah. No, that’s very well articulated. I think it’s really well thought out there. Ultimately, it 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.

Stephan Livera: That’s often the way I’ve thought of it as well. It’s sort of like, rule one of Bitcoin, as Andreas says, not your keys, not your coins. Rule two is, know your node, know your rules. I think the way we teach this, and, obviously, many of my listeners probably are more intermediate or advanced themselves anyway, but that’s kind of, you got to baby step people through. You kind of just sort of take them straight from leaving their stuff on the exchange to now fully running your own node.

Stephan Livera: You’ve got to say, “Okay, what’s one step further? Okay, take it onto a one-hardware wallet. Okay, now you’ve got a one-hardware wallet, let’s try to get you to a multi-signature, hardware wallet set up. Okay, and 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.

Michael Flaxman: That’s exactly the path, and the beauty is, they’ll do it themselves, because I get calls at each step of this on the way. I mean, the typical path I’m used to getting is, someone’s on the order page on a Coinbase or now a Square Cash, and they’ll say, “Hey, 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, but you’re probably going to get your Bitcoin. It’s probably going to be okay.” Then they say, “Hey, I’ve got like $10,000 on this site. It seems kind of sketchy. Should I start it myself?”

Michael Flaxman: I’m like, “Absolutely. Yeah, here’s all these different ways you can do it.” Then they run a hardware wallet, and they say like, “Hey, this hardware wallet, maybe Bitcoin’s price has gone up in this time,” and they say, “This is 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.

Stephan Livera: Well. No, I mean, agreed with you, but it may be actually 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.

Michael Flaxman: 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.

Stephan Livera: 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? Actually, you’ve got a really great website now with this https://bitcoin-hardware-wallet.github.io/ I’ll put the link in the show notes, obviously, but Michael, just tell us a little bit about what you’re trying to achieve here.

Michael Flaxman: Yeah. 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. I 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 of … I played with it before, but I hadn’t gotten into details. Basically, 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.

Michael Flaxman: Multi-sig 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. I mean, 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 tweet storms and sub tweet storms and responses, but it’s very hard for it to be organized, so I created this just silly comparison site. It’s bitcoin-hardware-wallet.github.io, I should probably buy a domain name for it.

Michael Flaxman: It gives star ratings for each of those criteria to each of the main hardware wallets. Multi-sig 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’s like, “Yeah, it’s just it would rate so low.” I mean, I don’t know, 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 Kobo Vault that has a beautiful QR code, but it’s really made as a shitcoin wallet and it doesn’t seem to have much Bitcoin support, and they’re just not compatible with multi-sig with other hardware wallets.

Michael Flaxman: It’s not even difficult. They just don’t do it, but if they did, I wouldn’t mind their shitcoining. It would be only additive and they have a beautiful QR code. It’s really expensive. It’s like a $500 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.”

Michael Flaxman: 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 multi-sig 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.

Michael Flaxman: 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 year-ish old. We 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.

Michael Flaxman: 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.”

Stephan Livera: Yeah, that’s great. I particularly like how you can mouse over, you mentioned it there, 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, “Okay, what are these hardware wallets, why did it get rated that way,” that’s an important factor. Also, look, I think it is important to have some level of curation.

Stephan Livera: 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. Okay, I guess, are there any other points that you wanted to touch on with hardware wallets? I mean, there’s a lot we can go into. It might be nice to just, at least, touch on a few of these other points. Oh, there is that chosen nonce attack. I thought it might be interesting just to talk about that as well.

Michael Flaxman: Yeah. Oh, 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, and one of the … it’s just a reality of ECDSA. ECDSA is the Elliptical 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 Adelson. 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’s website.

Michael Flaxman: 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 that, 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, very simple and straightforward. Actually, one by a former guest of yours, Stepan Snigirev, who’s a quantum physicist and a very sharp guy.

Michael Flaxman: 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 probably 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.

Stephan Livera: Yeah. Sorry. Just to clarify then-

Michael Flaxman: This is complicated. I’m sorry.

Stephan Livera: Yeah, there’s a lot here, but just to clarify then, 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, like the master private key?

Michael Flaxman: 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. So yeah. The severity of this tack, 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.

Michael Flaxman: 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 that was known that it was out there, then people would say, “Hey, don’t use this hardware wallet anymore. You got to upgrade or change.” You’ll probably have a limited window to try to get these inflight 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.

Michael Flaxman: This is a complicated one. It’s a nuanced one. There are some defenses for 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, multi-sig, because if you know everything about one hardware wallet, that you would possibly know, and you’ve completely pawned it, but there’s two signatures required, that’s still okay. That’s the amazing one. We could go into details of any of these attacks that are all scary and obscure and maybe what affects you or maybe 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.

Stephan Livera: Yup. Right. Also, this question of, is a secure element required or is it … Actually, is it just simply not as important as you mentioned of as just having multi-sig support?

Michael Flaxman: Yeah. I mean, I wouldn’t even consider … To me, multi-sig is an absolute must. If a hardware, while it is not designed to do multi-sig, 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 multi-sig 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 shitcoin trading, because we support thousands of altcoins and you can trade them on our platform. We’ve got a builtin integration perhaps with something like a ShapeShift. We’ve got partnerships for you to buy Bitcoin through us and other coins.”

Michael Flaxman: 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, or I think that’s still true.

Michael Flaxman: It was the fewest lines of code by a ton 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 multi-sig really is the most important thing. 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.

Stephan Livera: Right. Yeah. Let’s talk about an aim now, for some listeners who are trying to up their game in terms of security. Let’s say they wanted to try and run, say, Bitcoin Core with hardware wallet interface back at home and have, say, some multi-signature hardware wallets set up and they’ve distributed them. Is that a good aim for them? What’s your thoughts there?

Michael Flaxman: I think right now, for the security, usability trade off, if you want to do multi-hardware wallet, multi-sig, you should use Electrum. I don’t love that, because the Electrum has the problems about privacy and enforcing consensus rules, but you can run your own Electrum server in addition. If you switch to the Electrum multi-hardware wallet, multi-sig, you’ll be better off than the hardware wallet’s standard app that 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.

Michael Flaxman: 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 multi-sig, 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 and 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.

Michael Flaxman: 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, which 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?

Michael Flaxman: 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 Bitcoins 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.

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

Michael Flaxman: 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% of the time, and it’s pretty doable to do 99.9%. 99.99% uptime, that you can achieve, but that doesn’t just happen. You have to do some work, but if you want five nines, oh, you’ve got to be good.

Michael Flaxman: 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% 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% chance,” but maybe I want it to be 0.01 or 0.001 or 0.0001, but then you’re really going to have to do each extra step.

Michael Flaxman: 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 Bitcoins, 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, multi-sig, without any command line knowledge. I think we will be in a year, but we’re not there today.

Stephan Livera: Yeah. Look, that’s great. Thank you very much for that. I suppose maybe we’ll just summarize it then for the listeners. I think probably the two main lessons, I guess, one is multi-signature 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.

Michael Flaxman: 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, in addition to, your hardware wallet and backup strategy, but it’s a neat different thing that is kind of like multi-sig, 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.

Stephan Livera: Oh yeah. You know what, let’s do it. We might as well. Let’s cover it.

Michael Flaxman: Shamir’s Secret Sharing scheme comes from a 1979 paper by Adi Shamir. Again, he’s the S and RSA.

Stephan Livera: One of the RSA.

Michael Flaxman: He’s one of these crypto OG bad asses we have that are, surprisingly, still around. Ralph Merkle’s still around, the guy in Merkle tree. Adi Shamir published his 1979 paper called How To Split 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 an 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.

Michael Flaxman: 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 minus one, they get nothing, so it’s strictly superior to any other secret dividing construction where people are like, “Oh, I’m going to take my password and cut the paper in half and I’ll put half the password at home and half at work.” It’s like, well, first of all, if you lost either half, you’re in trouble. You would rather have two of five than two of two, or two of three or two or four. You could set your thresholds however you want.

Michael Flaxman: Also, it’s not really perfectly secure, because if you had one half of it, let’s say you had a 15-character passphrase or password and … Oh, let’s say 16, so the math is easier, and you have eight characters in one place and eight characters in another. Well, if somebody finds just the eight characters, they could brute force the other eight. Whereas with neither of them, they might not be able to brute force the 16. Depending, assuming randomness in your key space, your mileage may vary in terms of the numbers you put in. But the idea is, it’s a very clever and smart algorithm that people have been using on the periphery of Bitcoin for a long time, but it’s not commonplace. Here’s why it’s so useful.

Michael Flaxman: 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.

Michael Flaxman: 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 two of five, it could be 11 of 20, and you hand out these pieces to your passphrase.

Michael Flaxman: 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 and, combined with the physical seed that you’ve kept in your, say, safe 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, so they haven’t worried about it. Maybe it hasn’t been worth that much, but yeah.

Stephan Livera: But my question then is, how would you add that into your hardware wallet multi sig stack [crosstalk 01:43:02], would say, because here’s the thing, I don’t know if they’re different. For example, Casa go with the seedless approach. For them, when they’ve got their three of fives, 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, obviously, as we’ve talked about today is this idea of having multi-signature hardware wallets and maybe you distribute it out. Say you wanted to roll your own three or five, but then, where would the Shamir’s Secret Sharing come into that?

Michael Flaxman: Yeah. One of the things that it’s tricky in all of this is, first of all, we’re remembering 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 safe deposit box and they’re like, “Oh, I 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 multi-sig?

Michael Flaxman: Unfortunately, right now this is pretty messy. There is a Trezor, or SatoshiLabs, which Trezor has a slip, SatoshiLabs improvement proposal for Shamir’s Secret Sharing scheme and 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 multi-sig and HD, this gets very complicated.

Michael Flaxman: If I’m looking at a Shamir share of a seed, of a mnemonic … Let’s say I’m looking at a Shamir share of an xPriv, so a seed, for an HD wallet that’s two of three, I’m looking at a six of 10 Shamir share of a two of three multi-six 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 a Bitcoin Core and it said, “Oh, I know how to read all this stuff. Here’s your money.” Right now, it gets messy. It really does.

Michael Flaxman: 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. Like, they would have one of your keys, and you would have two other keys and it’s two of three. 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.

Michael Flaxman: 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, well, 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, and 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.

Stephan Livera: Always good advice.

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

Stephan Livera: Yeah. Look, I think, yeah, it is a bit complicated, but I suppose it’s just a matter of people sort of starting on that pathway. Right now, there’s a lot of people who are just leaving it on an exchange. Those people can just take one step further and that’s really where we’re going at with this podcast.

Stephan Livera: Look, I think that’s pretty much all we’ve got to cover for this. I mean, 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.

Michael Flaxman: 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, is michaelflaxman.com. That’s M-F-L-A-X-M-A-N, MFlaxman on Twitter.

Stephan Livera: Awesome. Well, look, 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.

Michael Flaxman: Thank you. Hopefully, I’ve helped them more than confused them.

Leave a Reply