Episode 101: The COLDCARD Hack

Aaron van Wirdum Live from the internet, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Hey Sjors. Yeah, we're doing another remote episode because, well, we promised to make one in our last emergency broadcast. So we're going to discuss the cold card hack as many other podcasts have done before us and many articles and, you know, everyone has shared their opinion. We thought we should still make this episode and I can pick your brain on this a little bit. It's sort of your expertise. Needless to say, COLDCARD is not our sponsor, at least not for this episode. We haven't really discussed it. I don't think we're going back.

Sjors Provoost No, they stopped sponsoring podcasts in general. That's my understanding.

Aaron van Wirdum Yeah, okay, right. Yeah, luckily we have a new sponsor,

Sjors Provoost That's right. That's right.

Aaron van Wirdum Mt. Gox. Mt. Gox, check it out. It's a brand new, brilliant Bitcoin exchange. Perfectly fine to store your Bitcoin. I hear they have Litecoin coming in two weeks from now.

Sjors Provoost Oh, nice. I should try that.

Aaron van Wirdum Yeah, jokes aside, that's actually something I also want to discuss. We'll do that a bit later in the podcast because obviously, so I want to discuss the cold card hack itself and then also... Yeah, kind of share my thoughts, your thoughts on them being our sponsor, because that kind of became part of the whole story that, you know, COLDCARD, Coinkite was sponsoring like every podcast out there. And to what extent, you know, are we to blame for all of this? Where do our own responsibilities begin and end? It sucks what happened. It's painful. But let's first discuss the COLDCARD hack itself.

Sjors Provoost Let's do that.

Aaron van Wirdum By now, probably everyone knows at least roughly what happened. But still, Sjors, what went wrong here? Obviously, everyone knows about the news. The cold card turned out to be vulnerable in basically the worst way possible. People that, as they say, did everything right. They generated their seed on a hardware wallet, never used it online even. But still, Bitcoins were being drowned from it.

Sjors Provoost Yeah, so...

Aaron van Wirdum Just in short, not to dwell on it too much because everyone knows this, but what happened?

Sjors Provoost No, I guess there are sort of two bad failures for a hardware wallet. One is if somebody can steal the coins from your hardware wallet if they have physical access to it or through some trick, like with, you know, we've talked about earlier with malicious PSBTs or tricks with fees, like malware on your computer, basically. And the other that is actually much worse, and that is what happened, is if the seed was never secure in the first place. And that's basically what happened, right? The seed had too little entropy. So basically the number of possible seeds in the world was just a couple of

Aaron van Wirdum Yeah, too little randomness.

Sjors Provoost trillion, I think, which is just not enough. It needs to be, you know, 256 bit or 128 bits. So like the number of possible seeds should be more than the number of molecules in the universe. And it wasn't.

Aaron van Wirdum Yeah, the core security function of Bitcoin, I think you can put it that way, like the central reason that your Bitcoins are secure or should be secure is that the private key or the private keys or whatever the private keys are derived from is... A number that's so big that it's impossible to guess even with all the computers in the world, blah, blah, blah. There's just too many, too many.

Sjors Provoost Yeah, I mean, it's one of the foundations, right? The other foundations are that the cryptography itself is secure, because if tomorrow it turns out that the SECP curve is insecure, then everybody loses their Bitcoin. And the

Aaron van Wirdum Right.

Sjors Provoost third one, I guess, is proof of work. If that doesn't work, then Bitcoin is also insecure in the sense that you just can't reliably make transactions anymore. But you can't steal somebody's coins then, but yeah.

Aaron van Wirdum Yeah, you can double spend, etc. But yeah, at least one of the core security assumptions in Bitcoin is that when you generate private keys, then it's going to be random and out of such a big amount of possible numbers that no one can possibly guess it. And that's what went wrong here, right? So again, it's

Sjors Provoost Yeah, and then the question, of course, how it went wrong, how that went wrong.

Aaron van Wirdum also a core file, arguably, or maybe not even arguably, just... The number one most important thing that a hardware wallet is supposed to do is generate one of those random numbers. And it turns out that the way these random numbers were generated meant that they weren't exactly random or not random enough. And then the question is indeed,

Sjors Provoost Well, I would say it's obviously it needs to be done correctly. I would say the number one task of a hardware wallet in general is to keep the secrets safe. But if it is not capable of making it securely, then it shouldn't make it securely, right? Then it should say, look, I'm not going to make a secret for you. You make it yourself and give it to me. But if the hardware wallet makes the

Aaron van Wirdum right,

Sjors Provoost secret, then it has to do it correctly. Otherwise, yeah, it's terrible.

Aaron van Wirdum yeah. Yeah, so that's what went wrong in a nutshell. And then, yeah, so let's get into a little bit of the technical nitty gritty of what the actual problem was. Why did this not happen?

Sjors Provoost Yeah, so the cold card has a chip in it. I think it's a secure element chip. And one of the things that secure element chip can do is make random numbers. And making random numbers is, you know, it's not that easy because you need lots of entropy from the universe, essentially. So there's, I don't know how these chips do that internally. They might just measure some noise in the environment, electricity, whatever. Whatever they do, they create a secure random number. And as far as we know, they do that correctly. So that's always a bit scary.

Aaron van Wirdum Yeah, and so I made a, just real quick, I made a whole episode on hardware wallets. That was one of the few episodes I made without you. Back a couple of years ago, I made it with Lawrence Nahum of the Jade Wallet and Ben Kaufman of Spectre. And COLDCARD is one of the wallets we discussed. And what I remember from that is that... Yeah, so the secure element, we don't actually know how that part works internally, right? In the case of

Sjors Provoost Yes. So what can go wrong, if

Aaron van Wirdum COLDCARD. So the randomness is generated in some way that we, yeah, we don't actually know how it's generated in the case of the COLDCARD, I believe, right?

Sjors Provoost you only use a secure element to generate the entropy, then at least the outside world has no way of knowing how that works. Why? Because these secure elements are typically patented and secret.

Aaron van Wirdum Yeah, but that's not, but that, to be clear, that wasn't, to be clear, that

Sjors Provoost But you can compensate for that by generating

Aaron van Wirdum wasn't the issue here, right? That's not the, no, exactly. Okay, so, yeah,

Sjors Provoost no, exactly. No, that's the kind of thing that still could go wrong with other hardware wallets or even this one. We don't know, right? But there are ways to compensate for that.

Aaron van Wirdum yeah.

Sjors Provoost But let's assume that the secure element just did its work, right? If it doesn't, then you would expect even older cold card versions also to start being drained, and we haven't seen that. No, something went wrong in the software that then sits on the cold card between you and the secure element. And its job was, and it did that correctly initially up to 2021, its job is to ask the chip for entropy, basically, and then use that. That's the simplest way to frame the job. Now, the problem here is that if you're running software on, well, let's go back a little bit. As a developer of hardware wallet firmware, you need to be able to test things. And the way you typically do that is in a simulator on your computer, not on the device itself. You probably do both, right? But it's a bit easier to work on a simulator because you need to quickly change something, try it, and you don't have to flash the firmware all the time. And therefore, the code somehow needs to work on both these environments. It needs to know whether it's running on the device or whether it's running... On the simulator. But that's a little bit dangerous because you don't want...

Aaron van Wirdum Simulator, just to be clear, is basically a regular computer. It's what we're

Sjors Provoost Yes, but that means it does not have that secure element. Might have another

Aaron van Wirdum talking about. Right. Yes, right. Right.

Sjors Provoost secure element, but not the same one. And so then the question is, how do you make that code work on both these environments? One very naive way is to say, I'm just going to check in real time where I am. But that's kind of dangerous because if... If you're trying to inspect how the device works, maybe something goes wrong with that check in the software in real time. And you don't want it to fall back to the simulator way of doing things. Also, sometimes you just can't even compile it because you can't run actual hardware wallet machine code on a normal computer sometimes because that chip doesn't exist. So the simulator is like, I don't, you know. I can't simulate that chip. I can simulate everything else, but I can't simulate the chip. There's some reasons why you can't run the exact same code on both the device and the simulator. And that's where languages like C have things called macros. And a macro is a way to say, or one thing you can do with a macro is to say, if I'm on the device, compile this code. And if I'm in the simulator, compile this other code. So the actual code that's compiled is different for the simulator and the real device. And the bug happened basically in that distinction. So the compiler would basically use some of the simulator code on the real device. Not all of it, but some of it. And in particular, the most critical bit of it, namely how to make the random data. So the real device uses or should have used the secure element to generate the random data. The simulator instead uses a Python library to do it. And that Python library was deliberately not actually cryptographically random. And that's fine because that Python library wasn't designed for any of this. But this is also where it gets really dangerous if you want to detect it.

Aaron van Wirdum Okay. So,

Sjors Provoost Because let's say the simulator had a very, very, very weak random number generator that only produces the number one. Like whenever you call it, it just says one. Well, that means anytime you run the simulator, you get the same seed. And so it'd be very obvious. And then if you had this bug, then the devices would all be making the same seed. That would have been caught like almost immediately, right? The first. QA probably would have seen it. And otherwise the customers would be like, why is there money on my account? Why is my money disappearing from my account? Right?

Aaron van Wirdum yeah, which some people did claim even happened now, but we'll leave that aside.

Sjors Provoost Collisions, right? So I think the number of secrets that these devices were

Aaron van Wirdum Yeah.

Sjors Provoost generating with the bug is still in the trillions. And then you can do some math on how many you need. I always forget. I think it's the square root. So you need a million devices to have any chance of overlap. But ask a statistician.

Aaron van Wirdum Yeah, it's the birthday paradox, probably, right? And anyways, like I said, let's

Sjors Provoost So probably not. Yeah, exactly.

Aaron van Wirdum leave that aside. Yeah, you were saying if the randomness is like really bad, then it's obvious enough for anyone to detect. And if it's really good, then there's no problem. But it's this awkward middle space where it's still kind of good-ish and then no one...

Sjors Provoost Yeah, it's a very, very dangerous middle space, right? It's good enough that you

Aaron van Wirdum Yeah.

Sjors Provoost can fool a human tester. It's probably even good enough that you can fool an automated tester because let's say you... As a company, you might have 100 test devices or 1,000 test devices, and you could connect them all via USB to some computer and have that computer constantly flash it and make a new seed, make a new seed, make a new seed, and then see if there's any overlap. So if the number of random numbers was maybe 10,000, You know, maybe the machine would have caught it. But the number of unique outcomes, I think, is in the billions or more. And so it was good enough to fool the humans, good enough to fool any kind of automation, even good enough that users wouldn't see these like, hey, why is there money in my fresh wallet? But not good enough to defeat an attacker.

Aaron van Wirdum Right. So in short, the problem as you describe it is that the test code was ultimately used as the real code on the device. That's the bug, basically. Is that a good shortcut to explaining it?

Sjors Provoost Yeah, not all the test code, right? But the very critical part of the test code. Yes. And so, you know, then you can look at how do you prevent problems like

Aaron van Wirdum Right.

Sjors Provoost this? Well, obviously,

Aaron van Wirdum Yeah. Or how could this happen in the first place?

Sjors Provoost yeah. So how it happened?

Aaron van Wirdum You're a developer, right? Like, is this not an obvious thing that you would see? Apparently not, right? Because no one saw it for a long time.

Sjors Provoost No. Well, I guess it depends, right? If your expertise is embedded systems, and you saw the change that was causing this, say, the switching between two libraries, maybe you would have noticed it. You're like, hey, this is a sloppy change. But if you look at the final result, maybe you wouldn't because it's very subtle. I think it's the difference between ifdef and if zero. So one says, is this variable defined? And the other says, is this variable not zero? And these are quite typical mistakes to make in code. We run into them in Bitcoin Core multiple times where some components shouldn't be included or should be included. It's just not happening in any critical place.

Aaron van Wirdum Right, okay, so,

Sjors Provoost But there's a second bug that made this worse. Or, you know, this bug could have existed and nothing would have gone wrong if there were some other things that had happened. So that might be useful to get into.

Aaron van Wirdum okay, and just to be clear, because there's different versions of the gold cards, right, and some of them were affected more than others, so what you just described, there was test code, and even though the secure element presumably worked, the test code didn't call on the secure element for the randomness, and it was,

Sjors Provoost The real code, yeah, exactly. The real code didn't use the test path to get the randomness instead of the secure element.

Aaron van Wirdum yeah, and is this the MK3 problem already, or is there more to it there as well?

Sjors Provoost No, that's what happened on MK3. But even on MK3 could have been prevented with additional randomness. So there's something quite nice about entropy, which is that if you take bad entropy, so low entropy, not enough randomness in it, and you add to it very good entropy, or the other way around, I guess, easier to understand. If you take very good entropy, so completely quantum number generated noise, and you add to it bad entropy, like just the word hello, it doesn't matter. Like you do not weaken entropy. Entropy only gets stronger. Entropy just increases if you add it. That's a very nice property. And that means what you can do is you can take, once as a device that's trying to generate a key, you can take the entropy from the skewer element, and then you can start adding other stuff to it. And the coldcard was doing that a little bit, but not enough.

Aaron van Wirdum Right. The MK3 also.

Sjors Provoost I think so, yes. I'm not sure. I think, yes, the amp-key3 added a little bit about the timing of where it was in the boot sequence. Because if you just take the Python random number generator that they used without any other data, then they would have all had the same seed because it was a deterministic random number generator. This always produces the same thing

Aaron van Wirdum Oh, right. Okay.

Sjors Provoost given the same input. So they already, in a way, added a little bit of entropy, but it was just not enough. But typically what you do is you generate your seed, or sorry, you generate some entropy with one source, and then you XOR, it's like an addition, essentially, another source of entropy into it, and you just keep doing that with other sources. And these other sources can be, well, on a normal computer, you can take a screenshot off your desktop, you can measure, you can read a bunch of files, just random files and hash those. You can look at mouse movements. I don't know if people used PGP back in the 90s, but then you'd have to wiggle your mouse for like a minute for it to have enough entropy to create a secure PGP key. I don't know if that was actually true or

Aaron van Wirdum Yeah, also with the original paper wallet websites

Sjors Provoost just therapeutic, but

Aaron van Wirdum that you had in like 2013, 2014, that was also a thing.

Sjors Provoost yeah, but some of these paper wallets were highly insecure despite that.

Aaron van Wirdum I know I'm not recommending them, but I'm just pointing out that was like a thing

Sjors Provoost Yeah,

Aaron van Wirdum back then. And should

Sjors Provoost so mouse movement makes sense. Now, the problem with hardware wallets is they have less of that, right? Because they are isolated devices, they have very little software, so the file system is very predictable. It's not like you can just look at somebody's desktop background or whenever they last opened their email. There's none of that on the hardware wallet. It's much more sterile, much more similar. So it probably wouldn't be enough to just look at random things on the hardware wallet. The hardware wallet also doesn't know the actual time in the universe. It just knows how long it's been awake. But that's typically very short because you're just creating a new one. So things you could probably do is have a gravity sensor or accelerometer. You know, your phone knows which side is up because it knows which way the gravity is pulling on the sensor. And so if you just tell the user to rotate their device a couple of times and you have such a sensor, that could be an additional source of entropy. We just tell the user, like, shake the device for, like, two seconds. And you just add that to what the secure element is giving. Some hardware wallets, I think, nowadays have cameras. Those are great, too, for entropy. Because they just take, essentially, they just take photons from the universe. And these are all just completely unique. Assuming the camera is working, right? If the camera is black, like there's nothing coming in, well, then they're all the same. So you would never want to rely on any of these single sources. The sensor is broken, it's not giving random data, then you still have a problem. So if they had done that, that would have compensated for this, basically. But on the MK4, there was an even better situation, in theory, because they had multiple secure elements. And they were combining entropy from all three of them. They just did it wrong.

Aaron van Wirdum we... About the MK3 real quick, because that's the worst one, the one that's worst effective. So I think what we just described about the test code and all that, that's true for all of them, right? For all reasons, once, but

Sjors Provoost Yeah, that's the fundamental thing that went wrong. What I just described after

Aaron van Wirdum then some added, yeah, but then some,

Sjors Provoost this is like, what could have made it less bad?

Aaron van Wirdum yeah, but then some did make it less bad, right? So how do you know the differences between like what else went wrong or didn't go wrong or what

Sjors Provoost Yeah.

Aaron van Wirdum mitigation did some of the wallets still have?

Sjors Provoost Yeah, so what happened in the MK4 is that they did add more entropy, namely from these other secure elements. And if they had done that correctly, namely adding all the entropy from the other secure elements, then there would not have been a problem at all, because as long as one of them works, you're good.

Aaron van Wirdum Okay, so they did not do that correctly either. So what did they do then?

Sjors Provoost But they didn't. No. They took some entropy from these other devices, from these other secure elements, but then they trimmed it. So they only took, like, I think it was four bytes of it. 4 times 8 is 32 bits. So they had only 32 bits of real extra entropy.

Aaron van Wirdum So they took four bits out of how many?

Sjors Provoost Well, they could have taken infinity, but let's say normally you'd want a seed that's 256 bit, so 32 bytes. So they could have taken 32 bytes from one of the secure enclaves, taken another 32 bytes from the other one, and XOR all of them. So just take all the 32 bytes from each of the devices. But instead, they took only four. And I don't know why, because that is the kind of thing that I think anyone looking at that code would have spotted. But anyone knowing a little bit about entropy.

Aaron van Wirdum Okay, and this effect, correct me if I'm wrong. I believe so that they took four bytes out of 32 for a reason that you don't understand. But then this was itself also hashed again, right? With the Yasmarang. That's just a MK4 and your specific feeling.

Sjors Provoost Yeah, so the Yasmarang is this Python library. So the Yasmarang is this Python

Aaron van Wirdum Is that correct?

Sjors Provoost pseudorandom number generator. We talked about that in the milk set episode, about the general phenomena of a pseudorandom number generator. It takes some input. And it gives a random looking number, but it's actually, if you give the same input, you always get the same output. So it's not really random. And so if the input to that generator

Aaron van Wirdum Yeah.

Sjors Provoost is four bytes, essentially, four bytes of uniqueness, then you're only going to get four bytes of worth of entropy in the end. Because you essentially just have these four bytes and the pseudorandom number generator doesn't add anything. It's just four bytes in is four bytes out in terms of entropy.

Aaron van Wirdum So this really does sound like it's disaster upon disaster upon disaster then.

Sjors Provoost No, it's a disaster that could have been fixed in the MK4, could have been harmless in the MK4, but wasn't harmless because they didn't use the entropy they had, the extra entropy they had. They just didn't use it. So like

Aaron van Wirdum Yeah, well, that's a second disaster then, right?

Sjors Provoost you add two chips that could have given you... Yeah, I guess it depends on your definition of disaster. Yeah.

Aaron van Wirdum How would you call it? Blunder?

Sjors Provoost It's one disaster plus one bad implementation, I guess. I don't know. I don't know what the reason is why they only kept four bytes, but my guess would be that they did not have this intuition that good entropy plus bad entropy is good entropy. Because if you think, generally, if you think a nice cup of tea plus poison is just bad tea, right? But entropy doesn't work that way. You can just add as much badness or poison. So they might have just mistrusted these other secure devices. They're like, well, they're different manufacturers, but we don't fully trust them, so we don't use all of it, what's coming out of it. But that's the wrong intuition.

Aaron van Wirdum Right. Let me pull this apart real quick just to make sure that I understand and then hopefully our listeners also. Because I do want to point out, it sounds to me there are three different mistakes that happened on different...

Sjors Provoost Probably more, but there's two critical ones, yeah.

Aaron van Wirdum Yeah, so the first one is that there was a bug in the firmware, in the code that made the COLDCARD use test codes, which therefore didn't pull the randomness from the secure element. That's one. We discussed that one. Two is only four bytes out of 32 were used when the secure elements were combined. Instead of just using all the randomness, they only use part of the randomness. And then the third mistake. Did I get this straight? Is that the Yasmarang thing is a pseudo-random, is not

Sjors Provoost Yeah, so another way to put that is to say,

Aaron van Wirdum even a random number generator at all, not a good one. So there were three

Sjors Provoost well, that is part of the test code. The pseudo-random number generator is the

Aaron van Wirdum mistakes in that sense.

Sjors Provoost test code. So you basically take on the... Yes.

Aaron van Wirdum Is that Yasmarang?

Sjors Provoost So what happens is on the MK3, you take nothing, you don't take the

Aaron van Wirdum Oh, okay.

Sjors Provoost random number generator, and you just give it to Yasmarang. And on the MK4, I think you did that, plus you then added

Aaron van Wirdum Okay.

Sjors Provoost real secure elements, but you only added four bytes of them.

Aaron van Wirdum Okay, I see. So then there's...

Sjors Provoost And I think those did not go to the Yasmarang. So it's like you take nothing, you put it through Yasmarang, and then that's one source, and then you add another source, but you don't add the full source.

Aaron van Wirdum Right.

Sjors Provoost And that first one, I think, could have been missed in a security audit of that part of the code. The second, I don't understand it. I mean, of course, everything can be missed. And it depends on what you tell an

Aaron van Wirdum Okay.

Sjors Provoost auditor and what that auditor's experience is. You know, if you tell the auditor, like, make sure nobody can steal the secret, then they might not even look at this part of the code.

Aaron van Wirdum Yeah, so let's get there next. But first, does this cover the bugs? Like the actual mistakes, you know, the heart of the disaster. Does this cover that part before we move on to? Yeah. OK, so that

Sjors Provoost Yeah, I think so. I mean, you can make it more subtle, but those are the two things.

Aaron van Wirdum this is basically what went wrong. OK, so then, yeah, let's get into a little bit of, you know, how could this have happened? One of the one of the things I saw out there is. That, you know, one of the mistakes that were made is sort of a meta mistake is that the firmware, the source code itself was no longer open source since a couple of years. You know, the backstory is another hardware wallet manufacturer foundation. Wanted to take the open source code that COLDCARD was using. The Coinkite people, Novak, didn't like it. And they decided to turn the source code into source available rather than open source. Which, if I understand correctly, means the code is out there, but it cannot be commercially used by any other manufacturer or product. And this would have taken away, the claim is this would have taken away the incentive for other Developers, security, auditors, whatever, to actually properly look at the code. And that's why it could stay in there for so long. What do you think of this claim? Do you agree with this?

Sjors Provoost First, we should disentangle two things. One is the changing of the library is what introduced this bug, just the act of changing it, regardless of whether the new library was good or bad. It was the act of swapping the libraries where the mistake was introduced, the first mistake. But your question is more important, I think. I don't think that explains it. It's one of those things that could have made a marginal difference. Maybe some would have caught it. But you have to understand that Source available. If it was completely open source, then there would have been more companies using the source. Therefore, maybe more people incentivized to look at it. But if these companies would have just lazily copied the source and not looked at it, they might have made the same mistake. That's one aspect of it. The other is that there was quite an incentive out there to look at the source anyway. Because there's a lot of prestige for security researchers and competitors to find bad bugs in their competitor. And we know that companies, you know, there's been many conferences where people would show, oh, look, I can play snake on the ledger. Or like, look, you know, I can take a hammer and take the seed out of a treasure.

Aaron van Wirdum Right.

Sjors Provoost So we know people were doing that. People were spending quite serious money on trying to do that. So that's why I don't think in this case it would have made a difference. Just because you can't commercially reuse the software source doesn't mean you're not going to look at it. Another thing that's important is that the new library they use is kind of a wrapper library around existing ones that are free and open source. So it uses internally libsecp, you know, the library we did in episode two, I think about. And that's a very mature, very well audited library. The problem is that even libsecp tells you to bring your own entropy. So the critical part is something that's not in the library. So even if the library was completely fine, it wouldn't have mattered because it is basically the final part where you say, okay, give me some entropy because how you get entropy depends on the device. So if you are a hardware wallet, you have a very different way of getting entropy than when you are a software wallet. So that's just left to the wallet developer.

Aaron van Wirdum Yeah, I mean, this is what I'm getting at is that,

Sjors Provoost And that part is going to be unique anyway, and you can't really copy it without completely cloning the device.

Aaron van Wirdum yeah. What about, you know, I'm just going down some claims and just kind of picking your brain on, you know, because I... I do get the impression a little bit that there's a lot of, you know, it's a bit of Captain Hind sighting where, you know, after the disaster happens, you know, people are looking,

Sjors Provoost It's not entirely kept in hindsight because, like I can speak of my own experience, I have worked on two software walls, right? On the blockchain.com wallet back in the day when I was still blockchain.info and on the Bitcoin Core wallet. And in both cases, I've looked at some of that random number generation code. And so I know at least, you know, some best practices there. So in other words, I think if I had looked at this code, I would have caught the

Aaron van Wirdum okay, well, that's,

Sjors Provoost second problem. Not the first one. Not the wrong if def statement. I don't think I would have seen it. But the like, hey, why are you not adding much more entropy if you have it? That I would have complained about. In an audit, personally. It's not the kind of thing that you go on Twitter and rant about. But it's one of those.

Aaron van Wirdum yeah, yeah, yeah, but my question is a bit more. Yeah, but my question is a

Sjors Provoost Right? So I think other people with this experience would have seen that too.

Aaron van Wirdum little bit more because now you're addressing like the software, the bug itself, which that's where, you know, I'm not an expert in that at all. And you are. So I

Sjors Provoost Mm-hmm.

Aaron van Wirdum believe you when you say that. But I'm a little bit more asking about sort of the meta behavior or best practices in the sense of, you know, how was the software developed? So indeed, for example, this difference between open sourcing and code available.

Sjors Provoost Mm-hmm.

Aaron van Wirdum Or another example that people have brought up is that the COLDCARD wouldn't have had like a proper bug bounty program. Like these kinds of things. How do you see these concerns? So you address the code available source.

Sjors Provoost Well, the bug bounty program, like I said, I don't think that matters because there's enough prestige to find these bugs without a bug bounty program. I mean, it's not that, you know, it would be nice if they did, but I don't think it's going to make that much of a difference. There is an incentive to look.

Aaron van Wirdum Yeah.

Sjors Provoost The other part is the open source versus closed source. Now, it's been a few years, but I have actually made a pull request to the cold card to add some descriptor support like many years ago, you know, with Bitcoin Core. And so they, at least then, I don't know if they still do it, but... They then did have a somewhat collaborative culture where other people would contribute to their code. And people, I don't know if they're still doing that, but that's a way to get eyes on your code. One of the problems in open source is that you can publish and you can make it free, like in Libra, as much as you want, but if nobody contributes to it, they're also not going to look at it. So there's plenty of, there might

Aaron van Wirdum Yeah, sure.

Sjors Provoost be, you know, super critical code out there that is completely free and open source, has a giant bug in it, and just people don't see it because nobody's looking at it. I

Aaron van Wirdum Yeah. Yeah. Well, to that point, another, you know. The complaint or concern that people brought up is like, were there or should there have been like formal security audits on this kind of code? And if there weren't, then why didn't that happen? Do you have any thoughts on that?

Sjors Provoost mean, I guess you can come up with a, you know, a regulatory framework where you can say like, hey, if you are producing hardware wallets or some class of security products, you need to do this and this and this audits. That's a government thing. Or like, you know, it's a marketing thing where you say, we have, even without the government intervention, you can say, look, we have this security audit. That's a part of your marketing then. And the customers can decide whether they want to buy a product that has this certification or not. Now, of course, we know that all sorts of certification schemes can become paper tigers. Like the DigiNotar example in the Netherlands, where like a domain. I think it was a top-level domain provider or something that passed all the audits, but they were completely insecure. So I don't know if that would have helped. But maybe it is good to have some sort of quality standard. But then still, what do you tell the auditor? Which auditor do you hire? What should their expertise be? Sure, now you can hire auditors to look for the exact same bug, and you'll find it if it's in other devices. You don't know what the next disaster is going to be. And especially if you have a hardware wallet with lots of whistles and bells, bells and whistles, you know, at least the cold card and some other devices only support Bitcoin. But now imagine you need to audit a hardware wallet that has 15,000 shitcoins on it. And some of the bugs have nothing to do with the cryptography. They're just like... Oh, if you don't check this field in an Ethereum transaction, somebody can trick you into losing all your wallet. And that's a huge class of bugs that you're just not going to find in an audit. That's just a North Korean audit, basically. You find out when it goes wrong. So I'm not saying that they were fine, they did enough. I'm just saying I

Aaron van Wirdum Yeah, so,

Sjors Provoost wouldn't count on it that it would have... It's all incremental. More security audits, good. More open source. Instead of view only, it's all better. So you're just decreasing the chances by doing all these things better. And the other is just write code much more carefully with much more review. You don't swap a giant library into commits with 2,000 lines of code. That's not very good software development style. But again, if you look at software that, you know, in retrospect, when you find a

Aaron van Wirdum right. Well, that's...

Sjors Provoost bug, it's often in a sloppy part of the code base. But I don't know what that means.

Aaron van Wirdum Yeah, well, so I wanted to ask you, but you sort of answered it in a, well, kind of in a depressing way, you kind of non-answered it. It is like, how do we move forward? How do we prevent something like this? So all of these things would have been a bit better, you say, like it would have been a bit better if it was open source. It would have been a bit better if there were maybe security audits or, but. None of it would have necessarily prevented this. And probably there is no way.

Sjors Provoost No, there is, I mean, what is interesting here is that,

Aaron van Wirdum What are the lessons, Sjors? What do we learn from this, if anything?

Sjors Provoost well, this class of bug where you think you have randomness but you don't have enough has happened a few times before, right? We did an episode on Milksad where this wasn't an actual wallet, it was just a tutorial. The tutorial used to be safe and then something changed in the library and the tutorial is suddenly completely unsafe. But it wasn't obvious enough to immediately see it. And historically, there was, I think, the blockchain.info wallet just before I was there, or at least not in the area I was working on, on the Android wallet, where they were, again, they were using randomness from the device, and then they would fall back to some random.org website that would, you know, just in case, just give you something, right? And I think what turned out is that that website was gone, so it was just saying 404. So there's no entropy there. And then the device entropy either didn't work or they didn't take enough bits. And again, it wasn't obvious enough that users would say, hey, why do I have balance in my new wallet? QA wouldn't have seen it, but it was bad enough that anybody understanding what's going on could steal all the coins. And in that case, it was all, I think, sweeped by a good actor and eventually redistributed. This class of bug, there is some discussion of how you would prevent it. One line of argument would say make it an all or nothing proposition. Make sure the test code has absolutely no entropy in it so that it's very clearly test code. And don't add mediocre entropy. So don't add keystrokes or timing from the device because it's enough to obfuscate the bug, but it's not enough to actually save it. Whereas another line of thinking, which I kind of prefer, is saying, no, you should just add more entropy. Like you should make the device such that even if the secure element doesn't work, it doesn't matter. Like you have enough entropy from sensors and voltage and whatever it is. And just force the user to shake or type on the keyboard. Like those are kind of the two different approaches there. But that just deals with this particular issue.

Aaron van Wirdum Yeah, exactly. So, I mean, that's also great. And any issue that can be solved in the future is, of course, good. But at least in this sort of...

Sjors Provoost Yeah, and libraries are a good way to prevent bugs in general, right? So good open source, well-reviewed libraries like SecP make it less likely. But entropy is device-specific, is wallet-specific. So it's very hard to have a reusable thing because every physical chip is different. You're not going to have shared code there. It's just one project. So then the solution is, I guess you just combine wallets. So you use multisig and with MuSig too. If one device has a flaw, the other one maybe not have the flaw. Problem there is

Aaron van Wirdum Right, yeah, I mean, that's more a user-side solution, of course.

Sjors Provoost complexity. But that might be the only solution, because if everybody relies on a single

Aaron van Wirdum I was...

Sjors Provoost device, even if different people rely on different devices, then there's going to be bugs. It's just inevitable.

Aaron van Wirdum Right. Okay. So that's, you know, insofar that you want to give any, you know, officially Sjors mandated security advice, then you do think the sort of multi-fender hardware wallet, multisig setup, that's a good way to go.

Sjors Provoost Well, with this really, really big trade-off, that is complicated. And complexity is how people lose backups. People have two or three... And they assume that if they lose one of the three devices, they're fine. But they're not because you still need the xpub from that third device that you lost. And if you didn't... So it is, in theory, if we can get the software to the point where it's idiot-proof and everybody knows what to backup. But other than that, if you have to decide, like, am I going to, you know, what's my long-term risk? Is it... My device that I randomly bought, like I just pick one of the reputable manufacturers, I buy their device, put all my savings on it, and then hope that device is not the one that's broken? Or do I do this complicated multisig setup where now my risks are I lose my backup, I did something just wrong in the setup, I used a bunch of additional software to do this, that software had a backdoor and it was tricking me into sending money to the wrong place because it... Took over my browser and replaced the exchange address and I checked it on the devices, on multiple devices, the destination address, but the money went to the hacker because there was malware in one of these complicated pieces of software. Or do I use a third party that helps me with the multisig? There's companies out there. Yeah, now I've lost all my privacy because of the way they generally do that. Or I'm subject to KYC now. There just is no good way to deal with this, I think. We should continue improving things until there is. But currently, I think the current state of the art is you kind of, yeah, it's not good. And the solution is not like send it to a custodian because that's also not good.

Aaron van Wirdum Yeah, that's, yeah,

Sjors Provoost We already know that.

Aaron van Wirdum that's also my impression. And that's, you know, it sucks. And in a way, I've been saying this for a long time that I actually think, yeah.

Sjors Provoost I guess I can add one more point maybe. We probably shouldn't be writing off a cold card immediately either. Permanently, anyway. I mean, obviously, you probably want to, you know, ignore them for a year or so to see how they, you know, how they behave, if they really make their quality higher. But there aren't that many hardware wallets out there. And they all have trade-offs. You know, some of them have shitcoins, which means how many developer hours are actually going into the part that we care about versus how much goes into other stuff that might itself be a weakness. Some don't have secure elements, so they're maybe less secure against physical attack. We're not in a space yet where we have like 100 products, and if one of them fails and misbehaves, we just completely ignore them and we don't worry about it because there's 99 others out there. We're not there yet.

Aaron van Wirdum Okay, so you think Coinkite, COLDCARD, you know, can recover from this and in a way you're sort of saying they deserve a second chance even? Yeah, of

Sjors Provoost Technically, they can. I don't know if financially they can. They might get sued

Aaron van Wirdum course. Right. Yeah.

Sjors Provoost to death, basically.

Aaron van Wirdum Yeah, no, but...

Sjors Provoost But the spirit of, you know, and even if they don't, then hopefully they're nice enough to say, you know what, we as a company are doomed. We're going to completely open source the hardware and the software of what we have and we'll let other people take another stab at it. Though their bankruptcy lawyer might not like that because it's like giving away value. So, yeah, maybe that whole design is trapped.

Aaron van Wirdum Yeah, no, generally speaking, I, you know, this has been a, I think everyone agrees is basically a disaster for Bitcoin. It's a disaster for people that lost money. But also it really drills down, drills home the idea that there just is no good solution of how to actually. Store your coins. Everything has pretty significant tradeoffs. I personally don't know what to recommend anymore. I mean, I will make a best effort recommendation to, you know, whoever is asking, depending on the technical capability or how much Bitcoin they own. But the idea that there is anything resembling a one -size-fits-all solution is just not there, which is,

Sjors Provoost No, and then you start adding inheritance to the problem where some non-technical

Aaron van Wirdum yeah.

Sjors Provoost successor has to be able to use it. But also the $5 range attack shouldn't be able to take advantage of whatever that mechanism is by just triggering your inheritance basically. So yeah, it's a completely unsolved problem. We need to keep working on it. And this was probably maybe a warning to not think that we've already solved it.

Aaron van Wirdum Right. You briefly mentioned COLDCARD, Coinkite potentially getting sued or whatever, but as a more general point, what is your assessment of people potentially getting any of their money back if they lost it in this hack? Do you think there's a path to that at all?

Sjors Provoost Well, assuming that they catch whoever did it, right? If they don't catch it or if it turns out it was North Korea, then nobody's getting anything back. But let's say that the, you know, people think that some script kiddie used an AI and found the bug and then kind of in a rush took the money because there were some patterns that they were using APIs of Block Explorer services instead of just, you know, doing a very high OPSEC. And who knows? Maybe they used an AI with actual logging. Probably not. I don't know if they used AI. Maybe they didn't. Maybe they just looked at the code and realized what was going on. Anyway, let's assume that the money is retrieved. Then it presumably goes into some sort of foundation, either back to the company or like a dedicated vehicle that's focused on dealing with this because as a company, it's a massive distraction. Now such a vehicle could, I think part of the secret was, part of the mnemonic was derived from the device identifier, or at least the chip series identifier, something not unique, maybe not unique to devices, but at least narrows it down a bit. And so people can, if they hold on to the physical device, can use that device as part of the evidence that they are the owner. But the thing is, I don't think it's good enough that you can automate it. So you can't make a DAO. You know, like in Ethereum land, they might have set up a smart

Aaron van Wirdum Sure.

Sjors Provoost contract, put all the money in a smart contract, and then you can redeem yourself automatically from the smart contract. I don't think that's possible because the device just doesn't have a way to prove it, right? You can just use a simulator and pretend that you're the owner. That means humans have to be involved. And given that they're a company based in Canada, those humans are going to be very heavily regulated. That means anybody who wants to file a claim probably has to prove their funds, not just from a point of view of proving that you are the owner, but proving that you're not a criminal, right? So it's full KYC, AML. So that makes it even more tragic in a way because people who are doing self-custody, it's not even that they're trying to evade the law or anything, but they want to be independent of the system and they're kind of forced into the system to get their money back.

Aaron van Wirdum Yeah, I mean, I'm sure everyone would take that trade off at this point.

Sjors Provoost I don't see how you can just anonymously... Sorry?

Aaron van Wirdum I mean, I'm sure everyone would take that trade-off at this point if you at least get your money back that way or at least part of it.

Sjors Provoost Yeah, yeah, of course. But it's painful.

Aaron van Wirdum But yeah, so you're saying indeed there's an identifier in the hardware itself that could help. So if you're listening and your device was drained, don't throw it out yet because it might come in helpful.

Sjors Provoost Yeah, definitely don't throw it out. But then in addition, my guess is because you need to prove that you own those coins for legal reasons. And that also serves as proof that, you know, that makes it more likely that they're sending it to the correct person. So such an, I would imagine, some sort of trust or foundation makes an inventory of people who are making claims, all the evidence they've submitted, and then like a waiting period, say like, hey, if you think, you know, somebody's taking your money, let us know. And otherwise, we're just going to give it to the people who made a claim and reasonably prove that it was them, whatever's left. And then these lawyers are charging $1,000 an hour at least. Just draining half the pot and it's going to take longer than Mt. Gox. That's my guess. But if the Bitcoin price, you know, 10x in the meantime, then that might still be a decent outcome compared to losing everything.

Aaron van Wirdum Yeah, and then also one of the ways... Yeah, yeah. And then also one of the ways

Sjors Provoost You know, which is what happened with Mt. Gox, right?

Aaron van Wirdum you can potentially prove that these coins were yours is ironically to show the KYC records that you bought them and then exchange and withdrew or something like that. That could be one way.

Sjors Provoost Yep, exactly.

Aaron van Wirdum Okay, I think that's rough. Is there anything else you want to say about like either the bug or the aftermath or the process or anything we've been discussing so far?

Sjors Provoost No, I think we covered most of that or all of it.

Aaron van Wirdum Yeah, so then let's get into sort of our part because CoinKite was a sponsor of ours, of course. In fact, it seems that they sponsored the entire Bitcoin ecosystem or the entire podcastosphere, it looked like. And that's become part of the story also, like all

Sjors Provoost Quite a few, yeah.

Aaron van Wirdum these podcasters. They look stupid for promoting this hardware wallet now. And yeah, we're part of that. So yeah, I have some thoughts on that. I think you have some thoughts on that. As a sort of general question, yeah, what do you think we are part of the problem here?

Sjors Provoost I think that's a good question. And I'm not sure. Because... Like we know that sponsorships in general can cause problems, right? And especially on YouTube, like any sponsor you will see, you will be able to find out somebody debunking it as a complete scam. And that has something to do with the companies with the most budget, the most marketing budget causing being problematic. However, I think with a lot of these high budget sponsors out there, if you actually do some like... Asking around between competent people, they'll explain to you why it's not good. That was not the case here at all. There are many technically reputable people who are using COLDCARD right until the end. So it wasn't the case of, oh, if you just asked two technical people, they would have told you it's a scam. That's just not the case. So the question is, how much due diligence should you do as a podcaster? I think we did at least some by not just... I'm sure there would have been other companies, other hardware manufacturers out there that nobody's even heard of that are less good, basically.

Aaron van Wirdum Yeah, I can share my thoughts on this because you're touching on... I think there's kind of two aspects to it. Or first of all, generally speaking, you know, as media producers, or I would even say, you know, in my case, I think we're making a journalistic podcast ultimately, or at least I consider myself a journalist. And for better or worse, mostly for worse, For the most part these days, that is funded by sponsorships, advertisements, that kind of thing. In an ideal world, that wouldn't even be the case, right? In an ideal world, you could make media based on subscription models. And there are some examples of that that are successful or even donations or something like that. But other than that, for a... The overwhelming majority of media out there, it's funded through advertisements, sponsorships, and that's the case for our podcast as well. Although, I considered it more of a hobby what we were doing. We were not getting a lot of money out of it, as you know.

Sjors Provoost No, and that's kind of tricky as well, right? Because the budget is so small that we couldn't hire a separate auditor to investigate their product because it would just have been more expensive than anything we ever got from the podcast. But that's more of a situation because we are a small podcaster.

Aaron van Wirdum Yeah, but just generally speaking, the problem exists in journalism for a long time, which is essentially a journalist. Journalism is built on reputation and telling the truth and informing your audience in an objective way, essentially. While an advertiser or marketing that's in conflict with that, there's always a tension there. They want to... Use the reputation of the journalism, of the journalist, of the publication to sell their products. But it's not the same thing. It's journalism and marketing are kind of, you know, they need each other, but they're also in tension with each other. So then,

Sjors Provoost Yeah, and it's a combination of audience size and reputation, right? It's two equally sized audiences, but a more reputable journal is, as a sponsor, presumably more attractive. So the trust is part of the equation. Yeah,

Aaron van Wirdum yeah, of course. Yeah, of course. I'm just pointing there's a natural tension there always. That always existed. But there's also solutions for that, essentially. And I think there's two big responsibilities that we have and had. So the first of all, and this is the one you pointed out, is that we should do at least basic due diligence to make sure that we're not promoting a scam. If we're promoting something like OneCoin that's super obviously a scam and people are going to lose money if they invest in it, that's a bad look on us. We need to take some measures to avoid that. But I don't think that applies here. I don't think Coinkite or ColdCard was a scam. As you mentioned, there were a lot of people that looked at this product, including pretty serious security researchers. That did not see this bug. They did not find this bug. So it was a reputable company. And in fact, that's why we took them as a sponsor. One of the claims that's gone out there is, you know, Coinkite kind of bought off the entire podcasting system to sell their defunct products. But that's, speaking for ourselves, that's the opposite of what happened. We were happy that a reputable... Seemingly solid company wanted to sponsor it. That is why we said yes to it. It's not like some kind of hush. Yeah, it's not

Sjors Provoost I agree with that. And I actually liked the situation.

Aaron van Wirdum like we took hush money. Go on.

Sjors Provoost I like the situation much more than our previous arrangement where we had no control of the advertisements. I think technically we had some sort of veto, but when we were part of the Bitcoin magazine, they would splice in the ads and they would be for stuff that we wouldn't know anything about. Whereas now at least we had a sponsor that we didn't know.

Aaron van Wirdum Yeah, in our judgment, it was, and I would even say still is, like I don't think they were scammers. I don't think that is what happened. I think it was a disaster and a really bad bug, but I don't think they, you know, they stole the money. At least I would want to see real evidence before I believe something like that. I don't think that's what happened. And at the very least, I can say that, you know, no one, there was no one that suggested to us that we should drop them or, you know, that... We had them because we thought they were reputable. That's the reason we had them as sponsor. So I think that's our first part. We need to make sure that we're not promoting a scam. And reasonably thinking, I do think we did that. And then I think the other aspect is that we do need to make very clear. What is sponsored content essentially, right? Like what part of the podcast is us making content? Is me being a journalist and you being a Bitcoin core developer? And in what part of the podcast we're actually doing like an advertisement or a sponsored thing? And I do think also in that we were pretty clear in that. Like it was kind of over the top clear. I listened back to it and it's cringe to listen back to it, right? Because we are saying, or especially me, like I'm saying these very positive things about the cold card and indeed, even like over the top, like I'm calling it like a piece of art and these things, but at least

Sjors Provoost I think it was so over the top that it kind of proved that they were sponsoring

Aaron van Wirdum I,

Sjors Provoost us mostly just because they wanted to help out, not because they expected to make money from it. In a more serious, larger podcasting setup, I'm not even sure if any company would appreciate when there's so much tongue-in-cheek

Aaron van Wirdum right, yeah.

Sjors Provoost in the advertisement. I

Aaron van Wirdum Yeah, I think that's, you know, that's the second part of our response. Like the first part is, you know, it shouldn't be an obvious scam. And the second part, it does also need to be very obvious and clear that we're doing like an advertisement rather than content. And I do think we did that on both counts. So, yeah, it's a disaster what happened and it really sucks. And, you know, if we could turn back the hands of time, like we wouldn't take them as a sponsor. At the same time, I find it very hard to blame myself for it or to...

Sjors Provoost mean, if we had a time machine, and this raises all sorts of physics questions, but ignoring those.

Aaron van Wirdum We

Sjors Provoost If we had known about this bug earlier, we would have responsibly disclosed it

Aaron van Wirdum would have prevented it. Yeah, exactly.

Sjors Provoost and we would have told them like, hold off with sponsorship until you've fixed this totally, total vulnerability. Now, maybe a more realistic scenario would have been if we had known about... The precise engineering style or something. But again, it's not like I went to conferences and people were telling me, oh, you should look at that cold card software. It's absolute crap. Look, so sloppy. There must be a bug in there. That's totally not what happened. And that does happen with other projects. So, yeah.

Aaron van Wirdum Yeah, so I mean, the one thing I've been mulling over whether or

Sjors Provoost But obviously, if we had known there was a red flag, yeah, then we would have had

Aaron van Wirdum not...

Sjors Provoost to make that more ethical discussion. Like, do we want to have a sponsor knowing that we don't like how they do things?

Aaron van Wirdum Yeah, the one thing I have been mulling over is that, you know,

Sjors Provoost But I don't think that was the case.

Aaron van Wirdum in the... On the point of making it very clear which part of the podcast is us making content, is me being a journalist and you being a developer versus what part is sponsorship. It has become a norm in podcast land that... The same people, the hosts also do the ad reads. And again, in our case, it was tongue in cheek. And I think it was pretty obvious, but, you know, it is maybe better to not have that and to have what we had before, where it's just a recorded piece of audio. There's like some sound effects and you get a completely different person doing the ad like that. That is maybe better than what we did. So that that's sort of the.

Sjors Provoost I think that would be fine if the sponsor did not, like if let's say we have a new sponsor and they don't want us to be tongue-in-cheek about it but much more serious about it, then I think you would get into this territory where we might say, well, maybe we should just have another voice do it to make it clear that we're not endorsing something or, you know, to keep more distance, basically. Because it's not just about, I think that might be a good distinction. There's

Aaron van Wirdum Yeah, exactly.

Sjors Provoost the distinction between making it clear that it is an ad, but also whether you're endorsing it to what degree you are. I think in our case, you were doing it so tongue-in-cheek that, I don't know, but at the same time, of course, the fact that you list an ad at all is some level of endorsement. But a lot of sponsors will go much beyond that, right? They will say, oh, I personally use this, blah, blah, blah, all my wealth is on it. And then you get

Aaron van Wirdum Right.

Sjors Provoost into murky territory where I tend to agree with, then you really need a separate sound or a separate person to make that distinction. Like, yes, we think they're reliable enough to be a sponsor, but it's not more than that. But it depends on what it is. If it's like a conference, like, yeah, sure, go to

Aaron van Wirdum Yeah, I mean, and.

Sjors Provoost the conference. Like, that's not a recommendation that is dangerous to make, even if the conference is terrible. Like, that's not the end of the world.

Aaron van Wirdum Yeah, yeah, and not

Sjors Provoost But if you tell people, like, oh, put your life savings here,

Aaron van Wirdum to mention that there's, of course, also, I won't name any names, but there are, of course, also podcasts that, like, where the content is just recommending. COLDCARD, where it's not specifically an advertisement, but it's the actual host actually recommending, like, this is what you need to do. We didn't do that. Again, I think in our case, it was clear. I hope for everyone that there's a distinction between the sponsored part and us being a journalist and developer part. So, yeah, I mean, at the end of the day, I just hope no one got hurt. You know, I hope no one that listened to our podcasts.

Sjors Provoost None of our listeners, you mean, or not as a result of us recommending it. But, you know.

Aaron van Wirdum Yeah, that, well, both, I guess, yeah. But I mean, it's very possible, of course. Well, I do think in our case, because by the time we started our, not that this is important, but by the time we started having them as a sponsor, the MK4 was already out. So it kind of reduces the risk that maybe one of our listeners got the MK3 and their money is stolen

Sjors Provoost Yeah, I don't think that's a strong argument, though, because you could still

Aaron van Wirdum away. No, no, I mean, I'm not making an argument. I'm just, you know, some thoughts

Sjors Provoost say, well, no.

Aaron van Wirdum that have been floating through my head because at the end of the day, it does, you know, it is a disaster and it does suck that it happened to our sponsor.

Sjors Provoost Yeah, and, you know, even if the MK4 came out, like, somebody might have had an MK3, and because we talked about the MK4, they were like, okay, I guess Coldcard is solid, and I'm not going to throw it away and buy some competitor. So, but, I mean, you weren't making the case anyway, but I'm just... Thoroughly dismissing

Aaron van Wirdum Yeah, but so as a, I guess as a general question, like,

Sjors Provoost that argument. But

Aaron van Wirdum let's say, you know, one of the other reputable,

Sjors Provoost also, let's say we've had Ledger as a sponsor and their social media hack

Aaron van Wirdum well, I was just going to ask that.

Sjors Provoost happened and people got kidnapped. That wouldn't look good either. So again, they're not unique in this.

Aaron van Wirdum Yeah, or so to ask the question in a very general way to you, like let's say, you know, someone from Ledger or Trezor or Jade or Foundation or whatever, Bitbox. So someone is listening and they think, oh, they don't have a sponsor anymore. Let's reach out. Would we do anything differently compared to what we did? Like, is there anything we should have done differently in your view? Or is this just kind of a disaster?

Sjors Provoost Well, this comes to the bigger problem is our podcast is too small. So taking on a sponsor is not giving me any meaningful income. But it is exposing us to reputational risk. So I would say we just shouldn't take a new sponsor for that reason unless we scale the podcast or it's a really large amount. So it's kind of a difficult discussion for us. I mean, if we were to do it, yeah,

Aaron van Wirdum Yeah, I

Sjors Provoost you can do the things like having them record the audio and splicing it in, et cetera, et cetera. But I think fundamentally... It's like pennies in front of steamrollers. It was like 0.1% of my income, but it still

Aaron van Wirdum suppose

Sjors Provoost happens. I would have rather just paid the cost ourselves, right?

Aaron van Wirdum I agree with that. In our case specifically, it's the amount of money. We're a tiny podcast, no one listens to us, and the amount of money we were getting reflects that. We would have been better off to just not have a sponsor and consider it a pure hobby, which we're kind of doing anyways.

Sjors Provoost Well, look, in the beginning, we were doing at least one episode a week, and that would have been at least some reasonable income. But once we started doing four episodes a year, at the same time, it's nice to be paid by somebody because it's a form of appreciation, right? It does give you a motive. It does motivate you a little bit to see that people appreciate it enough to sponsor it. Yeah,

Aaron van Wirdum It made it feel a little bit real. It made it feel like we were making a podcast rather than just sort of friends hanging out and talking about Bitcoin for an hour. So, yeah. Well, we'll see. In case there is a potential sponsor listening, feel free to reach out and we'll at least think about it, I guess. But, yeah.

Sjors Provoost starting at 1 million a year. Yeah.

Aaron van Wirdum Okay, well, Sjors, anything else on this topic, on the topic of them having

Sjors Provoost No, I think

Aaron van Wirdum us as a sponsor or the bug itself or lessons learned or how to move forward from here or anything else?

Sjors Provoost we've covered a lot. So thank you all for listening to Bitcoin.

Aaron van Wirdum Explained.