Episode 83: The Milk Sad Vulnerability

Aaron van Wirdum Live from Utrecht, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Sjors, we're back. I know what you've been waiting for. It's my voice of an angel. It's time for... Sjors stacks sats, Sjors stacks sats, Sjors stacks sats.

Sjors Provoost OMG. So yeah, we have a couple, but they're not super distinct. One says from Farscapian, 32,000 sats. You guys are the best. That's always nice. And we have one that says the boost didn't work. Your node loses. And then they try it again. And then it did work. So the problem is I run my own...

Aaron van Wirdum It doesn't work. How did you get it? How can you read it?

Sjors Provoost So there's a difference between sending the boost and it actually... And I think... Yeah, what happens is the boost is split. So part of it goes to me, most of it, and then 1% or so goes to the Fountain app, probably. Depending on what podcast player is working. And it's not atomic. So the 1% to Fountain app will work, but if the payment to me doesn't work, then they only paid 1%, but they got to say their boost.

Aaron van Wirdum I see.

Sjors Provoost So that's not ideal. Ideally, it should completely work or completely fail.

Aaron van Wirdum It should be atomic, yeah.

Sjors Provoost But it's all new. And the problem is because I run my own node, not everybody is able to make a payment to my node, and so they might fail.

Aaron van Wirdum Right. Okay, Sjors, stacks sats. Sjors, today we're going to discuss Milk Sad.

Sjors Provoost Milk Sad.

Aaron van Wirdum So Milk Sad is, what is Milk Sad?

Sjors Provoost Well, it's the first two words of a very, very unsafe mnemonic.

Aaron van Wirdum Yes, and...

Sjors Provoost It's also the name of, the working name of a security disclosure that was in progress.

Aaron van Wirdum For the same reason.

Sjors Provoost Yes, well yeah they they found the security bug which is related to this Milk Sad and they needed a working name for it and they picked this working name and I guess it was it stuck.

Aaron van Wirdum Right, and it has to do with Libbitcoin that was that was… So I'm not sure if this is the right way to put it I guess that's what we're gonna get on in this episode is it a bug in Libbitcoin is that what it is?

Sjors Provoost Well, there seems to be a difference of opinion as to whether it's a bug or not. It's certainly a way to use Libbitcoin such that you lose money.

Aaron van Wirdum But someone published a CVE about it.

Sjors Provoost Yes.

Aaron van Wirdum That's for sure. So what's a CVE?

Sjors Provoost So a CVE is a, I forgot what the word stands for, but it has, I think it's like vulnerability, blah, blah, blah. It's basically a list, a public list of known security issues.

Aaron van Wirdum Right. So there was a security issue with Libbitcoin. I guess that would be a pretty objective, fair way to put it there.

Sjors Provoost Yeah, I definitely think so. I mean, one other way you could put it is like it's a security vulnerability involving Libbitcoin. That kind of leaves it open of whose fault it is. And it is a bit complicated.

Aaron van Wirdum Right. In any case, something happens and we're going to talk about it. Yeah. And it has to do with Libbitcoin. That one is for sure. It has something to do with Libbitcoin.

Sjors Provoost That's right.

Aaron van Wirdum Or is there still nuance left there? No, this definitely has something to do with Libbitcoin. So what is Libbitcoin, Sjors? Let's start there.

Sjors Provoost It's a library that is able to... It does a bunch of things. One of the things it's able to do is... It's a node, so it can sync the whole Bitcoin blockchain. But it's also a collection of tools that you can use without using the node. For example, to create a wallet or to do blockchain exploration stuff, I think.

Aaron van Wirdum Yeah, so it's a software library. It's not an actual library. Yeah,

Sjors Provoost Definitely not an actual library. And so it was quite popular. I think it peaked sort of in 2015 when most people were working on it. And I think it was at the time also used for certain stealth wallet projects.

Aaron van Wirdum Yeah, it was started by Amir Taaki and it was sort of the first non-Bitcoin Core implementation of Bitcoin. And then at some point Amir himself used it for DarkWallet, which was sort of the first really privacy-focused Bitcoin wallet, which is now defunct. But it's basically a collection of tools that you can use if you're building Bitcoin applications or anything. If you're writing Bitcoin software, you can take stuff from... the Libbitcoin library, right, is that a good summary?

Sjors Provoost Exactly, and when I say it peaked is because if you look at GitHub you can see a history of when there was most of the activity, most of the commits etc, and that really was many many many years ago. And over the last years it has been somewhat maintained but not super actively, right so right now if you wanted to pick a library to use for any Bitcoin project you may want to look for other projects.

Aaron van Wirdum Yeah, right now, Eric Voskuil is the lead maintainer of Libbitcoin. He took over from Amir, I think, in 2015.

Sjors Provoost Yeah, that's a long time ago, too.

Aaron van Wirdum Yeah, and when you say it was at its peak, so it sounds like what you mean is peak of development activity.

Sjors Provoost Yeah.

Aaron van Wirdum Not necessarily usage.

Sjors Provoost Usage we don't know.

Aaron van Wirdum Yeah, right.

Sjors Provoost Other than from this bug, which might give some indication, but it's like not even the main usage of it, so it doesn't really say anything.

Aaron van Wirdum Okay, now you just call it a bug. So you think it's a bug, Sjors? Yeah, I think so. How are we going to call it during the episode, throughout the rest of the episode?

Sjors Provoost Either a bug or an extremely poorly named command.

Aaron van Wirdum Okay, we're just going to call it a bug then. I think that's an easy word to use. I think Eric Voskuil will not be happy with that, but I think that's the word we're going to use. So what is this bug? What's the bug?

Sjors Provoost Okay, so basically there's a command at the moment called bx seed, where bx is the name of the computer program, the library, and seed says, well, what do you think that command means?

Aaron van Wirdum I think it means a Bitcoin seed, but I don't know what the command itself does.

Sjors Provoost Yeah, so it basically generates a Bitcoin seed.

Aaron van Wirdum Right.

Sjors Provoost Except that it does so in an extremely insecure way. And then somewhere in the documentation with some wording that you might, if you read it, means don't use this, but not really.

Aaron van Wirdum Okay, wait.

Sjors Provoost So basically it generates a seed, but the problem is the seed is based on an insecure pseudorandom number generator.

Aaron van Wirdum Let me break this down to see if I understand correctly. So Libbitcoin is a Bitcoin library. So there's all kinds of different parts of Bitcoin.

Sjors Provoost Yeah, I think it has commands to change say if you start with a seed has maybe a way to turn it into a private key or in a public key or in an address. Or

Aaron van Wirdum Yeah you're writing a software application, and you say I need this Bitcoin, I need to check if blocks are valid, well maybe that's a very big thing, but I need to do something. Let's get it from this library. And what you're if I'm understanding you correctly, one of the things you could get from this library is I need to generate a seed.

Sjors Provoost Yes.

Aaron van Wirdum Okay so that was the specific thing that was in the library that was the name of the specific thing in the library that was you would put it in your software if you needed to?

Sjors Provoost I don't know if people would put it in the software they would just type the commands as they were creating their own as they were manually processing something in Bitcoin.

Aaron van Wirdum Right. I mean, this is where my lack of, I've never developed like a wallet or anything else. So I'm still sort of struggling with how libraries work.

Sjors Provoost Yeah, in this case, I think a library is generally something that's used by another computer program. And I think in this case, I think this is more like a tool set. It's like a bunch of commands, utilities that you as a user would manually use to process something. So you just type something like, well, this command.

Aaron van Wirdum Okay you're at the entire library is on your computer, and then it's sort of some other software program you're using sort of refers to that library or you yourself refer to it, or you yourself and then it sort of goes to the library and uses that yeah it am I put it saying right? Okay so now I understand that part I think. And this thing in this library was sort of specifically labeled generate a seed

Sjors Provoost It was labeled seed.

Aaron van Wirdum It was labeled seed, Okay.

Sjors Provoost It wasn't labeled super unsafe seed don't use this.

Aaron van Wirdum Right, okay, then, the next question is why... So you're saying it was super unsafe to use. So why was it super unsafe to use?

Sjors Provoost Yeah, and the nuance there is that it started out as probably reasonably safe and it became unsafe later on. So we'll get into, I guess, in the history of that. But the unsafety lies in that there's only 2 to the power 32 possible seeds that it can generate. So about 4 billion different seeds that it can generate. Which is not a lot. Normally, your seed will have 128 bits in it, which is 2 to the power of 128. That is probably more possible seeds than the number of molecules in the universe, which I think is like 10 to the power of 100. Anyway, but in this case, it only generates 4 billion possible seeds. And then if you know that given a seed, so given the 12 words or 24 words, you know how to get to the first normal Bitcoin address, right? You do a bunch of derivations. Then you can basically take every possible seed and calculate the first address and the first private key of that address and just look at the blockchain and see if there's coins there.

Aaron van Wirdum So that would take probably...

Sjors Provoost A couple of hours on the laptop.

Aaron van Wirdum On a regular laptop you can, right.

Sjors Provoost Then if you want to be a little bit more sophisticated, let's say you want to find the first 100 addresses. Maybe it takes a few days but…

Aaron van Wirdum Okay, so to spell out the problem, it would mean, it would basically mean that anyone can just calculate any Bitcoin address that anyone could have possibly generated using that command right?

Sjors Provoost Yeah.

Aaron van Wirdum And this is what happened recently, I think.

Sjors Provoost Yeah, so what's interesting is that, yeah, so it was discovered because some people lost their money very suddenly and they talked to some security experts and there were two different people and it turned out when they looked at how they made their wallet originally, they were using that command.

Aaron van Wirdum To be clear, I mean, this is obvious probably to anyone listening, but this is basically the worst thing that can [unclear]— be in a Bitcoin wallet.

Sjors Provoost It falls in a, yeah, so these would probably be people who made their own wallet, right? Not people using a normal wallet software out there, but they thought, hey, I'm going to try and make my own wallet. I'm going to make my own keys. Maybe they use the hardware wallet and they didn't trust the hardware wallet itself to generate a reliable random number. And so they would use this tool to create the seed and then they would manually enter the seed into the hardware wallet. I think the case that the article demonstrates was from somebody who did that. Like, they had an air-gapped computer, so they knew pretty sure that whatever seed was generated was not exposed to the internet, and they manually entered it into a hardware wallet and then nuked the air-gapped computer.

Aaron van Wirdum Right. Okay.

Sjors Provoost But if your seed is unsafe, then it doesn't matter that you use a hardware wallet.

Aaron van Wirdum Yeah, exactly. That's why this is the worst thing that can be in a Bitcoin wallet.

Sjors Provoost Yeah, and these things have happened in the past in different variations, right? There was the problem of brain wallets, for example, where people would just randomly pick a few words and there's just not enough words. People are not good enough at really creating random words. And so people will automatically, anytime somebody comes up with that same idea, somebody will automatically sweep the blockchain. Now, specifically here, this was most similar to something that happened to Trust Wallet. Trust Wallet, as you understand, is a wallet you should trust and definitely not verify. And so people did trust it. And so what happened there is they were using, again, they were using this insecure random number generator. I think it was called Mers… Twist, some twist. I forgot which twist. And that was pretty much the exact same mistake as what was happening in Libbitcoin.

Aaron van Wirdum But not... The same thing. It wasn't Libbitcoin they used, right?

Sjors Provoost No, no, exactly. Trust did not use Libbitcoin. They just used the same random number generator. However...

Aaron van Wirdum Well, not random.

Sjors Provoost Yeah, but they said pseudo-random number generator. So the idea of a pseudo-random number generator is that it produces numbers that look random, but fundamentally they're not random. And that's not necessarily bad. Computers sometimes do that, but not with 32 bits. But the thing is, if you use with Trust Wallet, basically the same idea, somebody could guess all the private keys and Ledger Donjon, the organization within Ledger, did that.

Aaron van Wirdum Right.

Sjors Provoost So it uses the same algorithm, but with a slight difference in how it's applied to the seed eventually. And that's why, even though it's the same mistake, the Libbitcoin coins were not found in that way. Because I think it's something like you use the first part of the seed instead of the last part of the seed, something like that.

Aaron van Wirdum Okay, so let's get into... First of all, let's just get into the background now, I think. Because you said there's a lot of nuance in the background, or it used to be secure and then it wasn't?

Sjors Provoost Yeah, so one of the things is that this command was changed. So maybe we first want to explain why people were using this in the first place, because that is part of the problem. There's the book called Mastering Bitcoin, which is pretty good. But it had, I think inside the chapter that was explaining how addresses worked, it also showed some commands of how to make a private key. And one way to make a private key is using Bitcoin Core. And then the second one is, oh, you can also use this other tool, which is the Libbitcoin or its predecessor. And this was published in 2014 I think because it was in the second edition of the book. And at the time, this command seemed to be still safe.

Aaron van Wirdum You mean the Libbitcoin version that was in the book?

Sjors Provoost Yeah, or at least reasonably safe. I think they're still investigating. That might not have been perfectly safe either, but not as unsafe as it is now.

Aaron van Wirdum Okay, who's investigating that, and why was it maybe not even safe back then? Do you know this?

Sjors Provoost So the Milk Sad people are looking into it.

Aaron van Wirdum Oh, the same people that filed this CVE?

Sjors Provoost Yeah, they're trying to see, like, okay, this bug is clearly, like... When it became unsafe, you can see all the thefts happening. But it's possible that it was already unsafe, just less unsafe. And so they're trying to see whether that was also compromised.

Aaron van Wirdum Okay, but that sounds like it's just speculation. There's no evidence for that. Okay, so... Presumably, or don't assume maybe, but it seemed safe at least initially, what was in the book at first.

Sjors Provoost Yes.

Aaron van Wirdum Okay, go on.

Sjors Provoost Yeah, but there you can already say like, okay, if you're recommending something in a book, maybe you want to put a really, really strong warning above it. I think there was a warning above it in very general terms, like when you generate random keys, be careful. But I think even above every command, you probably want to say like, never use this. Because people go on Google and it's like, how do I make a Bitcoin wallet? And Google will just return some page in a book and you only look at the command and you don't look at the context and you type the command. So you cannot be aggressive enough in saying, don't use this. And especially if it's sitting right next to a command that uses Bitcoin Core, because that might give more of the idea.

Aaron van Wirdum Yeah, just because there was a lot of Twitter drama around this and I didn't read all of it. I guess one thing that I think Voskuil mentioned in this context is that from his part, it was not intended to be a recommendation or anything like that.

Sjors Provoost Yeah, that's very possible. So it's possible that Andreas wrote the book. He found this other way to do it using the Libbitcoin, added it to the book as just an example. I wasn't expecting people to use this for a serious wallet. Eric Voskuil, of course, wasn't writing that book, so he had no way to know. Now, what happened a bit later, and this is what has confused a few people, is that the Libbitcoin was changed. So the commands were moved around. So the original command was now different. And this change was not the thing that made it unsafe, basically. This was just a neutral change. It's just you have one command before, and now it's like you use a slightly different command.

Aaron van Wirdum For the same purpose?

Sjors Provoost For the same purpose. So the command bx seed now was something like sx newkey. It was just the same idea, just slightly different words to do the same thing.

Aaron van Wirdum Okay, wait. Okay, so the name, but was the current name already in the library as well?

Sjors Provoost No, so the library itself was changed. So what happened is this book was written based on an old version of the library. The library was changed. And then Eric went back to the book, basically, to the GitHub repository where the book is, because the book is open source, and basically changed all the commands to use the new version of the library.

Aaron van Wirdum Okay, so that would mean that, sorry, what was this part of the library code that this episode is about? bx seed or something?

Sjors Provoost Yeah, bx seed, that's the command. And it was a slightly different command before.

Aaron van Wirdum So was bx seed in the library back in 2013, whatever?

Sjors Provoost No, at the time it was called sx newkey, but it was the same thing. It was basically the same, essentially the same code, just with a different name. The library had a different name, the command had a different name, but it was doing the same thing.

Aaron van Wirdum And what was in the book?

Sjors Provoost It was using the original one, the sx newkey.

Aaron van Wirdum Okay, yes. But that was already insecure then, right?

Sjors Provoost Not as insecure as it is now.

Aaron van Wirdum I mean, I guess I don't understand why, but hopefully our listeners do.

Sjors Provoost When Andreas wrote the book initially in 2014, the command was probably secure or at least not as insecure. Yeah?

Aaron van Wirdum Yes.

Sjors Provoost Then, as far as we know, nothing was stolen back in those days. Then the library was changed, just the change of the commands. That did not change anything about the safety. That happened later. So what happened is because the library was changed, Eric would go to the book and say, hey, this library has changed. Please use these new commands now. And there was otherwise a completely neutral change. But I think some people interpreted it as if he added that library to the book himself. But it wasn't Eric adding the library to the book. Andreas did that in the original version. Eric was just saying, okay, if you're using my library, that's great, but it's changing, so use these new commands.

Aaron van Wirdum I guess my question or what I'm trying to get at, and maybe you were answering something completely different, is why does this insecure code exist in the first place? What is it for? Why would that even be a thing?

Sjors Provoost Well, this happened later, right? So what happened later is...

Aaron van Wirdum You're getting there?

Sjors Provoost Yeah.

Aaron van Wirdum Okay, great.

Sjors Provoost Another new version of the library came out. And that one made it unsafe. So the command didn't change, bx seed, still bx seed, but now suddenly it was changing. It was producing these 32-bit random things. So basically you have a book that's pointing to a library and people are using that command because everybody reads that book, you know, and then at some point something changes in the library. And so new people who are new in reading the book will actually do something that's unsafe, even though people who read the book two years earlier would have been fine, probably.

Aaron van Wirdum Okay.

Sjors Provoost Because you know yeah, the book doesn't control what's on the internet so you just…

Aaron van Wirdum Right I get that. Okay that makes sense. Why does this insecure code exist or I mean maybe I mean there's tons of… I'm just my question is basically is there a good reason for this to exist potentially?

Sjors Provoost No, I mean I think when the code was originally when that particular pseudo random number generator was designed is probably 20 years ago I think people thought it was secure, and then security researchers found out it was not secure. And since then you should just never use it.

Aaron van Wirdum So from what I understand, and of course you should correct me if I'm wrong, but I thought that basically the only randomness, which is then obviously not random was that it would only use like a timestamp.

Sjors Provoost Yeah. Effectively. I think it uses. A timestamp.

Aaron van Wirdum I guess at this point, we've discussed this before, so I think, so we don't need to get into detail exactly about all of this.

Sjors Provoost But I think it's a timestamp in milliseconds or in millions of a second, actually.

Aaron van Wirdum Yes, but that's the thing, right? So if you want to generate random numbers on the computer, the question is, how do you do that?

Sjors Provoost Yes.

Aaron van Wirdum And you usually use multiple inputs for that.

Sjors Provoost Including a timestamp.

Aaron van Wirdum Including a timestamp. But if you use only a timestamp, that's a problem because then... people can just try every time.

Sjors Provoost Yeah, but I think in this case...

Aaron van Wirdum Try every millisecond or whatever and find, right?

Sjors Provoost Yes, but in this case, I don't think the problem was using a timestamp. The problem was only using 32 bits.

Aaron van Wirdum Okay, and that's not the same thing necessarily.

Sjors Provoost No matter what the 32 bits is, if the 32 bits is a timestamp, yeah, that's fine. But if the 32 bits was the name of your pet, it's still not enough. So it's about the amount of data that was being used. Now, the reason people were able to come up with the Milk Sad thing is because if you set the time to zero, you can set your clock to zero, which is somewhere in 1970. Then it will produce Milk Sad. But you can't just hack somebody's wallet by guessing at what time they created it. You just have to guess every possible number.

Aaron van Wirdum So you'd have to do two things. You have to try every possible number and every possible time?

Sjors Provoost No, you just try every possible number. And the fact that this number happens to represent a time... probably the time in milliseconds since, you know, midnight or something like that. It doesn't matter what it represents.

Aaron van Wirdum Okay, back to my question. Is there, I guess your answer was no, but let me, so is there a good reason for this 32-bit code to exist? No, you say no.

Sjors Provoost To exist somewhere in the universe. I mean, code has been written and people don't, you know, always delete it. But if it's 2015 or whenever this change is made, and you want to use some random number generator, you shouldn't use this. Now you could say, and I think that was the argument, well, this function was never meant to be safe, so I was allowed to use a known bad library for this. I think that's not a safe way to do things.

Aaron van Wirdum So again, for me as a non-developer, I don't really understand how a library was written or used or so, I don't understand why why is this code in the first place? Is there a reasonable or feasible reason why it would even be there? That's sort of my question.

Sjors Provoost Presumably he just picked a way to make a random number from all the possibilities out there and he picked a particularly bad one, because presumably because he thought it wasn't important so it didn't have to be secure so anything that's kind of random was good enough.

Aaron van Wirdum Okay, so why would he think it's not that important? Is there…

Sjors Provoost Presumably because the intention of that function that he had in mind was that this function should never be used for real wallet. Should be used on testnet. So on testnet you can make a wallet that's perfectly unsafe and as long as it's kind of random it's good enough.

Aaron van Wirdum Okay, and it's easier to implement it that way or something?

Sjors Provoost This part I don't know, because there are probably very secure functions that are just as easy. Okay but I don't know that. So it may have been some reason why, because I did look at the original change itself why that change was made from something that was probably secure to something that's definitely not secure. And it had something to do with thread safety, which is completely unrelated to randomness. It's just a general thing in programming. So he's trying to fix a bug related to, I'd say, reliability of the software so that it doesn't crash. And in fixing that, he switched to a different random number generator, which presumably fixed the problem with reliability, just became unsafe.

Aaron van Wirdum Okay.

Sjors Provoost And again, not realizing that people were using this with real money.

Aaron van Wirdum Right. About that so from what I understand and I'm again I there's no reason for me to keep repeating this, but I don't know what… how how to develop a wallet. I don't know what process you follow. But apparently at least somewhere it said don't use this code for generating real money seeds or something on there was a warning it was somewhere right?

Sjors Provoost Pretty fake.

Aaron van Wirdum Fake. Okay.

Sjors Provoost There was a I would say a cryptic warning I I don't know the exact wording anymore. It did not say literally like never ever use this for a wallet. It said something indirect which I guess if you understood what it means you would have known not to use it.

Aaron van Wirdum Okay and Well, if you would okay I guess wouldn't anyone develop a wallet know what that means? Apparently not.

Sjors Provoost Anybody who is a wallet developer, but again we're talking about people not who are wallet developers but people who are just hand hand making their own keys. So there's a much bigger audience. So somebody just some random dude of the internet buys a hardware wallet thinks like yeah I don't trust this Ledger company to generate a random number because maybe it's exactly the same type of bug right? Maybe Ledger only makes one billion different keys and they know all of them and one day they just rug pull everyone right? So if you're worried about that, so then that guy

Aaron van Wirdum Would grab Mastering Bitcoin flip open the page that has this Libbitcoin seed use that one instead of the Bitcoin Core one.

Sjors Provoost Yeah, or probably he would google, okay yeah manually make Bitcoin wallet, and then probably Mastering Bitcoin shows up at the top or Libbitcoin shows at the top because other people link to it and would use that command now that is a bad process. So you can definitely blame the user. Like don't just use commands from the internet.

Aaron van Wirdum Okay. I guess my real question was, so you said it was a fake warning, but my other question is...

Sjors Provoost Vague warning, not a fake warning.

Aaron van Wirdum Yeah, fake. Yeah. Pronunciation. Where was this warning? Was it at least in the right place?

Sjors Provoost Arguably no. I think it was in some part of the documentation, but not in all parts of the documentation. I don't know. I haven't looked at it in that much detail.

Aaron van Wirdum What would have been the right way to do it in your opinion? Where would it have been or how?

Sjors Provoost I probably would have not called it seed, the command. I would have called it something like unsafe seed, just to be completely clear that you cannot use this. But of course, the problem is maybe he was working on this and completely forgot that this thing was mentioned in Mastering Bitcoin and some other places. Because the safest thing to do is to really sabotage it. If you rename it to unsafe seed, then anybody reading the book will type seed and it will just say error. I don't know what you're talking about. This command doesn't exist. And then that would trigger somebody to do some reading like, hey, why is this command removed? And then they would find some, maybe some more clear warning saying, you know, this command was used by some people, but you really shouldn't be using it.

Aaron van Wirdum Okay. And to be clear, wherever the warning was and however fake it may or may not have been, it definitely wasn't in Mastering Bitcoin. So someone who would...

Sjors Provoost No, exactly. I think Mastering Bitcoin said more something along the lines of whenever you make your own keys, you have to be very careful what you're doing. But then immediately proceeds to suggest...

Aaron van Wirdum Okay, and also, to be clear, so you do agree with Voskuil because he tweeted this, is that basically any half-competent wallet developer wouldn't—would have known not to use it? or would [unclear] clear?

Sjors Provoost What do you mean by wallet developer? There's like 10 wallet developers. People who actually make wallet software. Maybe those people would know, but I mean 99 of Bitcoin users are not wallet developers. They just make their own wallet.

Aaron van Wirdum I didn't I didn't make my own wallet. I just downloaded the wallet.

Sjors Provoost No, okay but the higher… You know the pyramid is bigger right? So the so at the top of the curve you have Andrew Poelstra he does not only make his own wallet he makes his own math that is used to make his own wallet right? Then you have people like uh I don't know sipa, Pieter Wuille, Andrew Chow, maybe myself. I work on wallet software. We're not in the same level, but someone like me, I make wallets. At least I've made two in my life. I've worked on two in my life. So yeah, I should not make that mistake.

Aaron van Wirdum Right, so how deep…

Sjors Provoost Arguably someone like Luke Dashjr shouldn't make that mistake.

Aaron van Wirdum You don't have to name a name I guess, or unless you want to but how far down this pyramid do we need to go before like who's the target audience to fall victim to this problem so to say?

Sjors Provoost Yeah, I would say anybody who question… Anybody who's paranoid enough to not trust the hardware wallets and that's you know everyone who uses Bitcoin who uses like who even uses a hardware wallet. And then everybody who feels confident enough to type some commands, which is, you know, not everyone, but it's still a lot of people.

Aaron van Wirdum Okay.

Sjors Provoost Maybe not you.

Aaron van Wirdum I mean, I'm not going to do that. No.

Sjors Provoost No, but there are plenty of people who know how to type commands. Like far, far more people know how to type commands than people who understand cryptography.

Aaron van Wirdum Oh, I mean, I've typed a command or two in my life, but I'm not going to type commands to generate seeds now. I don't think so.

Sjors Provoost No, that's fine. But I can assure you there are plenty of people who will do that. So there's a very large group of people, I think, who would very easily make that mistake. Now, how to prevent anyone from making that mistake? Like I said, you'd have to name the command something else and maybe even like force somebody to run a compiler or like put a bunch of barriers in place so people do not use it by mistake. I don't know where the responsibility of the library maker stops, right?

Aaron van Wirdum Yeah, okay.

Sjors Provoost It's still open source. If you use it, it is at your own risk. But I don't agree with that statement.

Aaron van Wirdum So it sounds to me like your position is more or less the fact that this code exists is not necessarily a problem. Like that was my sort of first intuition. Why would this even exist at all?

Sjors Provoost Yeah, because somebody one day 20 years ago wrote it thinking it was safe.

Aaron van Wirdum Yeah, okay. So that's not necessarily a problem. However, the fact that it was... named seed and it wasn't, like the warning wasn't clear enough, that that's really…

Sjors Provoost No, I think the fact that Libbitcoin used it at all was not a good choice.

Aaron van Wirdum Okay well that's what I was saying essentially. I mean okay that it exists in Libbitcoin I should…

Sjors Provoost Yeah, exactly, the fact it exists in the universe is fine. The fact it exists in Libbitcoin I I find that hard to defend. Okay maybe there was a good reason for it but I don't know.

Aaron van Wirdum Right, okay, I mean so my my best understanding…

Sjors Provoost If you do use it as a Libbitcoin author you should put like not just one but like infinite warnings like never ever ever ever use this.

Aaron van Wirdum I mean my best understanding is that it used to be testing code or something along these lines um… But yeah, but in that case, what you're saying, it was not labeled clearly and the warnings weren't clear enough. That's really ultimately the problem.

Sjors Provoost No, but none of this would have been a problem if Mastering Bitcoin didn't point to this. Because there's plenty of libraries out there that are also unsafe. Nobody uses them because they're not mentioned in some famous books. So it's a combination of circumstances, right?

Aaron van Wirdum Right. So then basically, Andreas Antonopoulos, I mean, I'm not into the blame game.

Sjors Provoost No, it's a combination of factors.

Aaron van Wirdum He's partly responsible then, right?

Sjors Provoost I wouldn't say responsible. It's more like Murphy's Law. If only one thing goes wrong, then nobody gets hurt. But if three things go wrong, like, okay, it's in a popular book, and it's a library that's well-known, and then something is changed in the library that people didn't really think about when they wrote the book, or even when they wrote the library. Some combination of things goes wrong, and people lose money.

Aaron van Wirdum Okay. That sounds like a very reasonable explanation to me.

Sjors Provoost And then even a very small group of people lose money, right? People who are not expert enough to write really safe wallet software themselves, but expert enough to do something stupid.

Aaron van Wirdum Right. So this brings me to the next point, which I bring up. So it sounds to me, you don't think this was intentional, as some people have suggested or even claimed? You don't think this was an intentional attempt to steal money by the Libbitcoin developers? That's not what you think?

Sjors Provoost I don't think so. Would have been, I don't know, they could have stolen more if it was intentional.

Aaron van Wirdum Right.

Sjors Provoost Let's see. I mean, there's a couple of other factors here why I don't think it was intentional. So I looked at one of the thefts that was listed in the article on milksad.info. And they list a bunch of transactions that were probably thefts. And you can click on these transactions in your mempool explorer or whatever, and you can look at the input transactions. So every transaction, the theft has inputs. Those are the victims. And then it has an output, which is the guy who stole it, presumably. And one of these transactions takes inputs from many, many different wallets. So they have addresses that are bech32, SegWit, basically, and they have all the way to legacy addresses. So I clicked on a bunch of these input addresses that looked old and looked at which ones are the oldest. And I found addresses that were funded in 2016. Let me see. Yeah, December 2016 was basically the first person who put money on that address. So basically people have been putting money on these addresses for years and years and years and years. But then the theft happens just a month ago. And that's interesting because it could have happened earlier, right? If it was a rug pull. Especially it could have happened in, I don't know, a bull market instead of a bear market. Like if but I don't know… Um the other factor is that this theft is I…

Aaron van Wirdum I think your logic here if I understand it correctly, could have happened earlier or later. Yes. Well, I mean but that doesn't prove intentionality or not right?

Sjors Provoost I mean it doesn't but it suggests it. It suggests that it's not intentional because the other factor I was going to mention is that about half a year ago Ledger found this bug that was essentially identical minus like one little detail. And so to me, the most plausible explanation is that somebody read the Ledger explanation and just started thinking like, hey, are there any other wallets that use this Twister thing? And they would Google around looking for this Twister thing and they would probably find the Libbitcoin code. And then they need a couple of months to figure out how to how to steal all that money in one go without…

Aaron van Wirdum Right, and on the other side of that argument, you would presume...

Sjors Provoost Because if it was deliberate, it could have happened before the Ledger incident.

Aaron van Wirdum Yeah, or at least you would do it immediately after, right? Because you would think, oh, someone's getting close.

Sjors Provoost Yeah, but probably you would have also taken the Ledger money.

Aaron van Wirdum Right.

Sjors Provoost Because you would have been like, huh, if I can make this backdoor, let's see who else does this by accident, right?

Aaron van Wirdum Okay, you were going to bring up a second point?

Sjors Provoost And yeah, in general, I think the timeline we just explained... it's pretty plausibly how something like this could happen by accident without any bad intention. I don't know what my second point was. I think I just…

Aaron van Wirdum Okay, well I can bring up a counterpoint just to see what you think about it. So I think um Lisa niftynei, she tweeted some sort of graph about how uh development activity on Libbitcoin stops basically immediately after something related to this happened. I don't remember what it was exactly. Do you?

Sjors Provoost Yeah, I think after the first exploit.

Aaron van Wirdum Okay.

Sjors Provoost So this is a case of, I think what she showed was a chart that looked at the commits on GitHub, like around the time of this exploit. So this would have been mid-July. And I think they showed like two weeks of activity and then nothing. And then there's the saying called, when in doubt, zoom out. And if you look at Libbitcoin over a long period, so I did it on GitHub, if you look at it from, say, 2014 and onwards, you see that it was very active in 2014, maybe 2015. Then it was almost dead, but with occasional spikes in activity. So every six months or so, there'd be some activity. And so the fact that there was a recent burst in activity that stopped, I think it's a complete coincidence. Or at least it also fits the pattern. Like they don't do anything and then for a couple of weeks they work on it and then it stops again. And I think it was the last change. No, no, the bug was introduced much earlier, right?

Aaron van Wirdum Yeah.

Sjors Provoost So the fact that it happens to have been one burst of activity, I don't know. And they didn't introduce the vulnerability now.

Aaron van Wirdum Yeah.

Sjors Provoost So it wouldn't—it [unclear] be causal, because whatever the mistake was made, like we said, in 2016, the first people put their money on those addresses.

Aaron van Wirdum Okay, so you think that's perfectly fine explained by coincidence, if there is even this correlation?

Sjors Provoost Well, first of all, it fits the pattern of these bursts of activity, and second, it doesn't make sense timing-wise, because the vulnerability was introduced in 2016 and not now. It was exploited now, but it was exploited, it was in place much earlier.

Aaron van Wirdum Okay, um I guess I mean obviously, I have no way of making any sort of reliable judgment on this. I would just be I… I mean, I would be kind of shocked if this was intentional. I've known Eric Voskuil for so long.

Sjors Provoost I would also be disappointed in the sense that it was only $1 million. It's like, really? 10 years, a career, 10-year career in Bitcoin and all you can do is $1 million? I'm not buying that. But anyway, from what I know, one of the original victims, one of the more sophisticated victims that realized what was going on and was able to reproduce it, filed a report with the FBI. So I'm sure somebody will try to figure out where that money went to. And then maybe one day we'll know who did it. But my guess is just some 16-year-old in his basement, read the Ledger post, did some digging, figured out how to do it from Libbitcoin, had to write some code to make sure he could do it all at once. Because if you just steal it from one, people will pay attention on Twitter. Somebody will figure out what happened and will basically... You get this white knight effect where somebody will try to preemptively take the money, put it in a safe place and then give it back to the original owners.

Aaron van Wirdum All right. What now? Are we at that point in the podcast or is there something else?

Sjors Provoost Yeah. What now is very simple. I think the Mastering Bitcoin new edition book will not recommend this particular tool. That means that maybe people won't do it. And I think the tool itself has made some changes to make it a little bit more clear. I'm not sure.

Aaron van Wirdum I mean, I guess it would be good to rename the tool as you suggested.

Sjors Provoost Yeah, personally, I would do something like rename the command so that anybody who's been using it, it will break for them. And then they can read the manual and think, do I really want to be using this? Or was this just a test that I was writing and it's fine. I'll just change the command. Because the problem is, of course, people will still read old editions of the book. So everybody, you know, some percentage of readers will think, oh, I'll use this. And you want to protect that percentage.

Aaron van Wirdum Right. Okay. I think, does that conclude our episode on Milk Sad? Is there anything we left out? Is there anything you want to add? Any hot takes?

Sjors Provoost Yeah. So there was the other question of whether there have been other wallets with the exact same bug. This was raised on Twitter, or X or whatever it's called by the time you're listening to this. There's a possibility that this particular bug was made by some other wallet and not all the coins that were stolen were from the Libbitcoin related stuff. I think that's unlikely because as we saw, as I said before, you had the Dojo—sorry, the Trust Wallet that had essentially the same bug as this one. But every wallet, or it seems like every wallet has its own fingerprint. So you start with this bad 32-bit randomness, and then you add your own fingerprint, which is slightly different for the Trust Wallet than from Libbitcoin. And if you don't know this fingerprint, you're not able to steal the money. Because otherwise, the money from this situation would have been stolen half a year ago. So my guess is if there's another wallet that uses the same insecure way to generate random data, they probably also have a slightly different fingerprint, which means that their coins would not be stolen. And also nobody was able to point to one. But it is possible, right? So the attackers stole coins that were protected by these insecure private keys, and it's possible that there were other wallet libraries out there that were generating the same keys. We just don't know which one.

Aaron van Wirdum Right, so we understand that Trust Wallet had a bug like this, but as far as we know, there is no other wallet implementation, no other wallet that uses, that has the same problem. So it's basically Trust Wallet has a problem like this and independently it's... guys that are slightly more technical than I am and use the command line. But we don't know of another wallet, but there might be because there's no way to tell on the blockchain.

Sjors Provoost There could be. However, you know, wallets are often open source. So you would simply Google all the source code out there for somebody using the same Twister random number generator. Maybe, but there could be some closed source wallet out there that, you know, uses the same thing.

Aaron van Wirdum We would have presumably heard it by now, don't you think? It's almost a week ago since this CVE or since this became public.

Sjors Provoost I don't know from who we would hear that. From whoever got there.

Aaron van Wirdum People on GitHub or Twitter or Reddit, I don't know. You know people. You're a well-connected guy, Sjors.

Sjors Provoost If it was another open source wallet doing the exact same thing, so not just using the same random number generator, but also using it in a certain way, right? Because there was a difference in the way that the Trust Wallet used it and the way that the Libbitcoin stuff used it. Then I guess, yeah, we would have known about that. But we wouldn't know about a closed source wallet. So you can't rule it out. Doesn't seem very likely though.

Aaron van Wirdum Okay. I think that's it. What's the moral of the story?

Sjors Provoost Be careful out there. So thank you for listening to Bitcoin

Aaron van Wirdum Explained.