WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.590 --> 00:00:22.610 Live from Utrecht, this is Bitcoin. 00:00:23.310 --> 00:00:23.750 Explained. 00:00:24.290 --> 00:00:25.550 Sjors, welcome back. 00:00:25.830 --> 00:00:26.210 Thank you. 00:00:26.470 --> 00:00:30.570 I saw you were promoting your book everywhere in the world over the past couple 00:00:30.570 --> 00:00:31.010 of weeks. 00:00:31.250 --> 00:00:31.690 Absolutely. 00:00:32.390 --> 00:00:32.910 Where did you go? 00:00:33.030 --> 00:00:37.190 I went to a place called New York, a place called Nashville, and a place called 00:00:37.190 --> 00:00:39.510 Austin. And those are all in the United States. 00:00:39.510 --> 00:00:40.370 That sounds very exotic. 00:00:41.130 --> 00:00:41.810 They are. 00:00:42.010 --> 00:00:44.490 And you were promoting your book. Which book is this, Sjors? Do you want to 00:00:44.490 --> 00:00:45.950 promote it on our show as well? 00:00:46.130 --> 00:00:50.990 Yeah. So in case nobody's heard of it, it is called... Bitcoin, a work in 00:00:50.990 --> 00:00:55.410 progress. And if you want to find it, because of the way that Amazon actually 00:00:55.410 --> 00:01:00.230 messed up the indexing, so they basically took the colon in the name, Bitcoin, a 00:01:00.230 --> 00:01:04.550 work in progress, and treated that one as a title and the other as a subtitle. So 00:01:04.550 --> 00:01:07.730 you want to look for Sjors Bitcoin, and then you'll find it. 00:01:08.170 --> 00:01:09.070 Great sales pitch. 00:01:09.230 --> 00:01:12.610 Or you can go to btcwip.com and you'll find it too. 00:01:12.770 --> 00:01:15.830 So I saw you promoted on Marty Bent’s podcast. 00:01:16.170 --> 00:01:16.530 Exactly. 00:01:16.830 --> 00:01:17.190 TFTC. 00:01:17.450 --> 00:01:19.990 Yeah, that was a bit unplanned because we happened to be in the same building. 00:01:20.550 --> 00:01:23.030 And they said, hey, do you want to come on the podcast? And then we can talk 00:01:23.030 --> 00:01:25.170 about the book. So we talked about that, Tales of the Crypt. 00:01:27.180 --> 00:01:30.800 Yeah, I saw that. So that's why there was no Bitcoin Explained episode for the 00:01:30.800 --> 00:01:36.280 past couple of weeks. But we're back, our dear listener, with this Christmas 00:01:36.280 --> 00:01:41.980 special of Bitcoin Explained. Actually I guess by the time this is released it's 00:01:41.980 --> 00:01:44.280 not gonna be Christmas anymore but we're recording it… 00:01:44.280 --> 00:01:46.680 Yeah the last episode of 2022. 00:01:46.680 --> 00:01:52.450 Pretty close to Christmas anyways. Yeah well I mean I guess it kind of depends 00:01:52.450 --> 00:01:57.690 on how I'm not 100 sure if our great super talented 00:01:57.690 --> 00:02:01.530 editors actually working between Christmas and new year's we'll have to… 00:02:01.530 --> 00:02:04.030 Well it's the last episode that was recorded in 2022. 00:02:04.030 --> 00:02:09.990 Yes that's for sure. So we got a very special for you today Dear listener, I 00:02:09.990 --> 00:02:14.970 hope you're strapped in. This is going to be a major one. Sjors is going to 00:02:14.970 --> 00:02:19.050 educate you about the most important development of the year. 00:02:19.330 --> 00:02:23.410 Yes, we have scraped the absolute bottom of the absolute last barrel that we 00:02:23.410 --> 00:02:25.870 could find after like an hour of brainstorming topics. 00:02:26.130 --> 00:02:29.750 We wanted to bring you something before the end of the year, because otherwise 00:02:29.750 --> 00:02:34.950 you would have had to manage probably five to six weeks without our voice. And we 00:02:34.950 --> 00:02:38.500 didn't want to do that to you, dear listener. So here we are. Back with an 00:02:38.500 --> 00:02:43.340 episode about a bug that was kind of in Bitcoin Core 00:02:43.340 --> 00:02:49.240 24.0 but okay first of all Sjors, let's let's back up 00:02:49.240 --> 00:02:54.440 a little bit here. Let's take it seriously it's a serious issue. Sjors, we had an 00:02:54.440 --> 00:02:57.340 episode on Bitcoin Core 24.0. 00:02:57.340 --> 00:02:57.740 Yes. 00:02:57.740 --> 00:03:02.620 And then that episode well no we aired the episode. But then the release of 00:03:02.620 --> 00:03:08.380 Bitcoin Core 24 was delayed by quite a bit and that was because a discussion 00:03:08.380 --> 00:03:14.380 about full RBF. There was an option to switch on full RBF in the Bitcoin Core 24 00:03:14.380 --> 00:03:20.330 node. And that sort of pushed back the actual release of Bitcoin Core 24 00:03:20.330 --> 00:03:25.950 and then finally Bitcoin Core 24 was released but then 00:03:25.950 --> 00:03:27.190 it kind of wasn't. 00:03:27.190 --> 00:03:30.910 Yeah that was a bug in it but the release was announced but if you went to the 00:03:30.910 --> 00:03:35.490 website bitcoincore.org you would actually still find version 23 so only some 00:03:35.490 --> 00:03:38.110 advanced users would have been able to download the actual release. 00:03:38.110 --> 00:03:43.920 And then so hang on is if Bitcoin Core 24 is 00:03:43.920 --> 00:03:47.220 not on bitcoincore.org. Is it really released? 00:03:47.540 --> 00:03:52.540 In a sense, yes, because there was a tag made on GitHub, which is signed, and 00:03:52.540 --> 00:03:56.020 there was an announcement. So people would be able to download it if they went 00:03:56.020 --> 00:04:01.560 straight to the FTP-like download site, where you just see the list of files, but 00:04:01.560 --> 00:04:04.500 not if you went to the main website, because that page takes a little bit longer 00:04:04.500 --> 00:04:09.010 for people to look at, and then that gets released as well. The page that points 00:04:09.010 --> 00:04:09.470 to the release. 00:04:09.730 --> 00:04:14.730 Wait, so does the page usually refresh automatically to include the latest release? 00:04:14.640 --> 00:04:19.090 No, there’s a pull… the website is on GitHub too. So people make a pull request 00:04:19.090 --> 00:04:23.950 to add a page that points to the new release. And maybe some release notes and 00:04:23.950 --> 00:04:27.270 other remarks. And that always takes a few days. And within that few days, the 00:04:27.270 --> 00:04:30.710 bug was found. And so that was postponed. 00:04:31.110 --> 00:04:36.230 Okay, I see. So that was technically an official Bitcoin Core 24 release. But 00:04:36.230 --> 00:04:41.090 that release never showed up on bitcoincore.org. What you do find on 00:04:41.090 --> 00:04:46.250 bitcoincore.org right now is Bitcoin Core 24.0.1. 00:04:46.450 --> 00:04:52.100 And this is because there was a bug in the original. Technically 00:04:52.100 --> 00:04:56.080 officially released Bitcoin Core 24 release. Is that right? 00:04:56.500 --> 00:05:01.300 Yeah, exactly. And when something like that happens, then the next release can be 00:05:01.300 --> 00:05:05.260 just called 24.0.1, basically not immediately 24.1. 00:05:05.480 --> 00:05:06.460 Yeah. Well, why? 00:05:07.000 --> 00:05:09.180 Because it's like a quick enough fix, basically. 00:05:09.500 --> 00:05:09.760 Okay. 00:05:09.940 --> 00:05:11.600 Probably nobody's going to be running the old version. 00:05:12.000 --> 00:05:18.000 Right. So that gets us to… Yeah so hang on so first of all so there was a bug in 00:05:18.000 --> 00:05:23.740 24 but that was not caught in the release process that's usually what… 00:05:24.420 --> 00:05:28.800 That's why there is the release candidates process, right? 00:05:29.120 --> 00:05:32.440 Yeah. So the idea is the release candidates, you hope that people test it and 00:05:32.440 --> 00:05:37.040 find bugs. But of course, not everybody's doing that and not everybody will be 00:05:37.040 --> 00:05:42.780 testing every single possible feature in every way that you can break it. So that 00:05:42.780 --> 00:05:43.720 was not found in time. 00:05:43.960 --> 00:05:48.060 Right. So a bug was found after it was officially released, but before it was 00:05:48.060 --> 00:05:52.400 published on the bitcoincore.org website. Okay, Sjors, What's the bug? What 00:05:52.400 --> 00:05:53.480 happened? What went wrong? 00:05:53.870 --> 00:05:58.710 Well, let's make a little suspension here. And I'm going to read some boosts from 00:05:58.710 --> 00:05:59.810 the previous episode first. 00:06:00.390 --> 00:06:04.650 Oh, yeah, we almost forgot about that. People are paying us money. We shouldn't 00:06:04.650 --> 00:06:10.650 forget about that at all. Go ahead, Sjors. And also tell our other listeners 00:06:10.650 --> 00:06:12.070 how they can pay us even more money. 00:06:12.650 --> 00:06:17.710 Yeah, so if you have an app that supports the podcasting 2.0 standard, there's 00:06:17.710 --> 00:06:22.070 multiple apps, Fountain is one, then you can actually stream sats to us. And if 00:06:22.070 --> 00:06:26.650 you Google something like podcasting 2.0 streaming sats and you'll find podcasts 00:06:26.650 --> 00:06:30.170 that explain that in more detail and then you can also send us a message which is 00:06:30.170 --> 00:06:33.910 called a boost and we got well we got a bunch of messages I'll just read two. 00:06:33.910 --> 00:06:35.430 These are the top paying ones? 00:06:35.910 --> 00:06:41.610 Yes, though we don't promise to take the top-paying… I'll read the amount and the 00:06:41.610 --> 00:06:47.450 name, etc. So we have at Banana Man, or Banana Man, depending on if 00:06:47.450 --> 00:06:52.530 he's British or American, paying 12,000 sats, saying episode 69. 00:06:53.110 --> 00:06:53.690 Nice. 00:06:54.450 --> 00:06:55.030 Nice. 00:06:56.010 --> 00:06:57.570 Okay. And then we have... 00:06:57.570 --> 00:06:58.030 Oh, that's it? 00:06:58.310 --> 00:07:04.190 Yes. And then we have a question from at user 6025638884, 00:07:04.330 --> 00:07:05.410 well, la la la la. 00:07:05.970 --> 00:07:09.490 No, no, this is important, Sjors. He's paying money. You better read his name 00:07:09.490 --> 00:07:09.930 right. 00:07:10.130 --> 00:07:14.290 No, these are default usernames that are created by the app. So that's fine. He 00:07:14.290 --> 00:07:19.960 or she is paying 10,000 sats and has a question, which is related to the topic we 00:07:19.960 --> 00:07:24.880 talked about earlier, naming RBF. What makes a non-RBF transaction new to a node? 00:07:26.290 --> 00:07:31.210 And when is it just another version? Is it e.g. considered a new transaction if 00:07:31.210 --> 00:07:32.690 some of the input UTXO changes? 00:07:33.170 --> 00:07:34.610 Sorry, can you repeat the question? 00:07:35.430 --> 00:07:38.210 What makes a non-RBF transaction new? 00:07:39.840 --> 00:07:43.980 What makes a non-RBF transaction new? All right, so what makes a transaction new? 00:07:44.220 --> 00:07:45.660 Rather than another version of it. 00:07:45.660 --> 00:07:48.240 Okay, yeah. Do you want to answer that? 00:07:48.840 --> 00:07:53.700 Yeah, so my guess is, I mean, it depends on how your wallet wants to interpret 00:07:53.700 --> 00:07:58.680 these things. In essence, a transaction spends outputs. So if any output is spent 00:07:58.680 --> 00:08:01.420 by another transaction, then that is a different transaction. 00:08:01.700 --> 00:08:06.620 I mean, I guess technically on a consensus level, any change to a transaction 00:08:06.620 --> 00:08:08.000 makes it a new transaction, right? 00:08:08.200 --> 00:08:08.500 Exactly. 00:08:08.780 --> 00:08:12.240 But there's some nuance here maybe when it comes to relaying. 00:08:12.380 --> 00:08:16.510 Well, what makes it new versus another one? You could have... If you have one 00:08:16.510 --> 00:08:19.730 input and one transaction and then another input and another transaction, then 00:08:19.730 --> 00:08:23.950 those are different transactions. They don't exclude each other. But the case 00:08:23.950 --> 00:08:27.270 we're interested here is when you're replacing a transaction, that means that you 00:08:27.270 --> 00:08:31.330 have another transaction that spends the same input or at least one of the same 00:08:31.330 --> 00:08:35.670 inputs so that only one of those two can exist. And then the question is, you 00:08:35.670 --> 00:08:39.250 know, what is new and what is old? Well, part of that just depends on what you 00:08:39.250 --> 00:08:44.000 saw the first. As a node before RBF, which would just be like, if I already know 00:08:44.000 --> 00:08:46.740 a transaction, then whatever else comes in [unclear]. But that could be different 00:08:46.740 --> 00:08:49.720 for different nodes because you might receive them in different order. But 00:08:49.720 --> 00:08:53.640 whether you call it another version or whether you call it new, it just depends 00:08:53.640 --> 00:08:58.170 on the interpretation of the wallet, how it wants to display it. So it could, you 00:08:58.170 --> 00:09:01.890 know, I think in Bitcoin Core, it'll put a cross through the old one and then 00:09:01.890 --> 00:09:03.730 just put the new one in its place. 00:09:04.560 --> 00:09:10.160 Yeah, I guess this question sort of derives probably from our conversation about 00:09:10.160 --> 00:09:15.800 these kinds of topics where we're using terms like new and version, but 00:09:15.800 --> 00:09:21.280 in actual Bitcoin protocol, there's no such distinction, I guess I would say, right? 00:09:21.800 --> 00:09:26.740 Yeah, exactly. So at least I think not because you have the nVersion field, but I 00:09:26.740 --> 00:09:32.600 think with RBF, it's just a flag. It's not a number that goes up. The only thing 00:09:32.600 --> 00:09:36.300 that goes up is the fee. So if a wallet wants to be a little bit smart about it, 00:09:36.340 --> 00:09:40.060 you could look at which one pays the highest fee. And then that has to be, that's 00:09:40.060 --> 00:09:44.340 sort of the newer one. That's probably intended as the newer one. So if you want 00:09:44.340 --> 00:09:49.140 to make a good wallet UI, you might want to show something that it increased the 00:09:49.140 --> 00:09:52.300 fee rather than showing two transactions. But that's really just up to the wallet 00:09:52.300 --> 00:09:54.880 authors, how they want to interpret what they're seeing on the chain. The 00:09:54.880 --> 00:09:57.240 blockchain doesn't really care. Well, the mempool doesn't really care. The 00:09:57.240 --> 00:09:58.360 blockchain definitely doesn't care. 00:09:59.180 --> 00:10:04.940 Yeah, I guess it's just way more binary. Either a transaction is valid or 00:10:04.940 --> 00:10:09.100 it's not. And if it's not, that can be because it's conflicting with the previous 00:10:09.100 --> 00:10:09.940 transaction. 00:10:10.660 --> 00:10:14.800 Yeah, but then valid in the mempool depends on your mempool policy, right? 00:10:14.960 --> 00:10:19.760 Yeah. All right. Well, that was maybe a very confusing answer to... 00:10:20.620 --> 00:10:24.200 I mean, it's a good question. It's a good question. 00:10:24.200 --> 00:10:28.120 I would also recommend people, if you have questions, also ask them on Stack 00:10:28.120 --> 00:10:28.580 Overflow. 00:10:28.780 --> 00:10:29.160 Yeah. 00:10:29.700 --> 00:10:31.520 Bitcoin or Stack Exchange because you'll get better answers. 00:10:31.700 --> 00:10:34.980 Like I said, I think the question kind of derives from our conversation about it. 00:10:35.120 --> 00:10:39.340 And it doesn't really map on the actual Bitcoin protocol. So that makes it a 00:10:39.340 --> 00:10:44.640 little bit hard to answer. But hopefully our attempt is at least worth something. 00:10:44.820 --> 00:10:47.480 How much did they pay for this answer? 00:10:47.600 --> 00:10:48.660 10,000 satoshis. 00:10:49.490 --> 00:10:52.370 All right. Do you think this answer was worth 10,000 satoshis? 00:10:52.450 --> 00:10:55.990 I think it was worth way more than 10,000 satoshis. 00:10:56.150 --> 00:10:56.670 Okay, cool. 00:10:59.970 --> 00:11:02.370 So then we're back to the main topic, Sjors. 00:11:03.050 --> 00:11:03.150 Yeah. 00:11:03.430 --> 00:11:07.010 Okay, listeners, strap in again. Here you finally get the answer you've been 00:11:07.010 --> 00:11:12.090 waiting for. Sjors, there was a bug in Bitcoin Core 24. That's why there was a 00:11:12.090 --> 00:11:16.610 Bitcoin Core 24.0.1 release. What was this bug? 00:11:17.270 --> 00:11:20.630 Yeah, it was a bit of a foot gun, basically. You could, well, not, I don't know 00:11:20.630 --> 00:11:24.290 if foot gun is the right word. You could lose a bunch of money. So in Bitcoin 00:11:24.290 --> 00:11:28.330 Core, when you're sending money, you can... Either let the wallet decide 00:11:28.330 --> 00:11:32.850 automatically which of your coins to use to send the money or you can manually 00:11:32.850 --> 00:11:37.170 specify exactly which coins you want to use or some combination of both where you 00:11:37.170 --> 00:11:41.430 say well I want to pay one Bitcoin to this guy and I want to use this specific 00:11:41.430 --> 00:11:46.360 0.3 Bitcoin coin that I have But other than that, you figure out which coins to 00:11:46.360 --> 00:11:47.200 take from the wallet. 00:11:47.580 --> 00:11:52.560 Right, yeah. When you're saying coins, the technical term here is UTXOs. I guess 00:11:52.560 --> 00:11:56.240 people that know that know what you mean anyway. So my addition doesn't really 00:11:56.240 --> 00:11:56.860 help anyone. 00:11:57.240 --> 00:12:02.120 No, that's fine. Yeah, so basically it's like the analogy is you have a wallet 00:12:02.120 --> 00:12:06.580 and there's a bunch of coins and paper notes in it and you have to pay something 00:12:06.580 --> 00:12:11.850 and you... Take one euro coin out of it you say I definitely want to use this but 00:12:11.850 --> 00:12:15.210 then you have some other guy going through your wallet and deciding which other 00:12:15.210 --> 00:12:17.430 coins to use to add up to 10. 00:12:17.530 --> 00:12:20.790 Well if you want to use the analogy sometimes when you're abroad in a country 00:12:20.790 --> 00:12:23.810 where you don't know which coins are what and you don't want to waste time you 00:12:23.810 --> 00:12:27.590 just sort of show all your coins to the merchant and then they'll just pick… 00:12:27.590 --> 00:12:28.790 The coin selection for you? 00:12:28.790 --> 00:12:30.150 Exactly that happens sometimes. 00:12:30.150 --> 00:12:31.170 I have done that a few times. 00:12:31.170 --> 00:12:32.730 So that would be the analogy here. Yeah. 00:12:32.730 --> 00:12:38.190 Yeah so anyway there was a bug in that where if you want to stick to the analogy, 00:12:38.750 --> 00:12:43.750 I think what happened is you would pick one of those coins and then it would 00:12:43.750 --> 00:12:47.530 basically, well, let's not use the analogy, you would basically select a couple 00:12:47.530 --> 00:12:52.950 of coins and then due to the bug, it would use those coins twice 00:12:52.950 --> 00:12:55.470 to calculate what was going on. 00:12:56.640 --> 00:13:02.120 Ah wait so okay so you got a number of coins UTXOs and when you're manually 00:13:02.120 --> 00:13:05.960 selecting them then for the fee calculation it would… 00:13:07.480 --> 00:13:10.260 Falsely assume that you selected them double? 00:13:10.260 --> 00:13:15.820 Yeah exactly and for some reason the net result of that mistake is that you might 00:13:15.820 --> 00:13:19.620 be paying a very very large fee because you think you're paying say I don't know 00:13:19.620 --> 00:13:24.840 one cent of fees but actually because you've counted this 10 euros twice it 00:13:24.840 --> 00:13:28.940 somehow includes it twice. Okay I don't completely understand how it happened. 00:13:29.200 --> 00:13:32.100 But that was basically the nature of the bug. So you'd be paying a very large 00:13:32.100 --> 00:13:35.820 fee. Now, fortunately, there is a warning system. If you pay a really, really 00:13:35.820 --> 00:13:40.990 high fee, it will abort. But there's another feature in the wallet where... So 00:13:40.990 --> 00:13:45.970 it's kind of a different kind of feature where you say, I want to pay this 00:13:45.970 --> 00:13:50.810 address. And I don't care about the precise amount. I just want to send this coin 00:13:50.810 --> 00:13:55.420 or this set of coins. You select the coins that you want to send over. So this 00:13:55.420 --> 00:13:59.580 can be useful for privacy. If you want to, you know, you receive your salary or 00:13:59.580 --> 00:14:05.560 whatever, and that's one coin, essentially. And you want to send only 00:14:05.560 --> 00:14:08.700 your salary to an exchange and none of the other coins in your wallet. You want 00:14:08.700 --> 00:14:12.280 to mix it. So you select your salary and you send it to the exchange. And if you 00:14:12.280 --> 00:14:16.140 use that feature in combination with this bug, you would lose even more money and 00:14:16.140 --> 00:14:22.120 the warning system didn't work correctly. As you notice, I'm being a bit vague 00:14:22.120 --> 00:14:26.610 because the actual bug... Is not described very well. That is the actual 00:14:26.610 --> 00:14:30.970 implication of the bug is not described very well. The bug itself is described as 00:14:30.970 --> 00:14:35.850 what was wrong in the code and that's pretty obvious. So yeah, there was a pretty 00:14:35.850 --> 00:14:40.850 bad ways to lose some money. So don't use 24.0, just use 24.0.1. 00:14:41.090 --> 00:14:45.190 All right. Well, so yeah, this sounds like a bug, a glitch. And I think you 00:14:45.190 --> 00:14:50.490 mentioned, I'm still going to ask, so how did this get into the code? How does... 00:14:50.540 --> 00:14:51.720 Why is this in there? 00:14:52.920 --> 00:14:56.280 Yeah, so this is interesting, of course, to look at what exactly went wrong here. 00:14:57.210 --> 00:15:01.870 So the bug itself was like one line of code that should not be there. I think it 00:15:01.870 --> 00:15:05.830 was a command called break, which jumps out of a loop, and that command was a 00:15:05.830 --> 00:15:09.890 mistake. Now, how does that get there? It was part of a refactoring. So 00:15:09.890 --> 00:15:14.190 basically, refactoring means you take an existing piece of code that may be ugly, 00:15:14.390 --> 00:15:20.300 and you rewrite the same code but prettier, in a way that it 00:15:20.300 --> 00:15:25.680 doesn't change any of the behavior. And so that's good because cleaner, more 00:15:25.680 --> 00:15:30.100 readable code in the future will lead to fewer bugs. However, you might make a 00:15:30.100 --> 00:15:34.740 mistake replicating the original behavior. And that's what happened here. So I 00:15:34.740 --> 00:15:37.820 think in practice here, there was a bunch of different functions that were 00:15:37.820 --> 00:15:41.560 responsible for removing. So if you take these coins that you've manually 00:15:41.560 --> 00:15:47.080 selected, then it would have to remove those from... Like another set of coins so 00:15:47.080 --> 00:15:51.520 that you don't select coins twice, something like that. And right, because the 00:15:51.520 --> 00:15:54.920 coin selection algorithm, it looks through the coins in your wallet. It tries to 00:15:54.920 --> 00:15:59.000 see which coins can I add to this transaction, but it shouldn't be adding coins 00:15:59.000 --> 00:16:02.140 that are already in your transaction. So it kind of had to do the subtraction 00:16:02.140 --> 00:16:06.630 there. And that code was doing the subtraction only once. I think it was only 00:16:06.630 --> 00:16:10.250 subtracting one coin that you selected, but not all of them. So this is the kind 00:16:10.250 --> 00:16:13.270 of bug that you might not see if you only select one coin. You'd only see if you 00:16:13.270 --> 00:16:18.450 select two coins. So it's, you know, difficult to run into this. So that was, and 00:16:18.450 --> 00:16:23.470 the cleanup there, like, I don't know, the code was doing 12 separate steps to 00:16:23.470 --> 00:16:27.730 remove… To remove these coins, and with the new version, it would only need two 00:16:27.730 --> 00:16:31.170 steps to remove the coin. So it was just cleaner. But I had the mistake in there, 00:16:31.210 --> 00:16:35.190 and the mistake was not caught. It wasn't caught during the code review by the 00:16:35.190 --> 00:16:39.370 people looking at it. There was also no test that failed. So there was no test 00:16:39.370 --> 00:16:43.410 where this precise scenario of adding two coins, et cetera, et cetera, was there. 00:16:44.780 --> 00:16:47.180 Because either could have caught it. Somebody could have caught it in a review, 00:16:47.360 --> 00:16:52.140 or some automated test could have caught it, but it didn't. And so the way that 00:16:52.140 --> 00:16:57.250 that is fixed… Is, well, first you fix the original bug, and second you add tests 00:16:57.250 --> 00:17:00.890 that would have caught it, so that at least the same bug could not happen again. 00:17:03.150 --> 00:17:07.170 That's pretty much what happened. And the other reason it wasn't noticed is that 00:17:07.170 --> 00:17:12.450 it was only in the release and not in the master branch. So that's an 00:17:12.450 --> 00:17:13.810 interesting aspect there. 00:17:14.700 --> 00:17:19.980 Okay, right. Okay, so the master branch is the main thing that Bitcoin Core 00:17:19.980 --> 00:17:24.260 developers work on. And once in a while, Bitcoin Core developers say, okay, from 00:17:24.260 --> 00:17:27.340 here on out, this is the new release. And they keep working on the master branch 00:17:27.340 --> 00:17:31.720 for new features. And the new release is going to be released. And somehow this 00:17:31.720 --> 00:17:32.900 bug was only in the release. 00:17:33.220 --> 00:17:37.680 Yes, exactly. Because what happened, the bug was introduced in this refactor. And 00:17:37.680 --> 00:17:41.970 then after that bug was introduced, the split to the release was made. And then 00:17:41.970 --> 00:17:46.070 somewhat later on master, the bug was accidentally fixed, not deliberately fixed. 00:17:46.590 --> 00:17:50.230 And the way you accidentally fix something is you do another refactor and 00:17:50.230 --> 00:17:54.070 something, and then you actually make another mistake because you're not 00:17:54.070 --> 00:17:57.570 replicating the original behavior. But because nobody wanted that original 00:17:57.570 --> 00:18:00.210 behavior, nobody would have noticed that either. So yeah, it was accidentally 00:18:00.210 --> 00:18:04.290 fixed on master. And that also has to do with the odds of finding it. Because who 00:18:04.290 --> 00:18:07.990 is testing Bitcoin Core? Well, part of it is people running the master branch. 00:18:08.170 --> 00:18:12.110 Those are probably other Bitcoin Core developers that are just trying snapshots 00:18:12.110 --> 00:18:15.800 of the master branch. You know, are not supposed to be very safe. It's supposed 00:18:15.800 --> 00:18:19.480 to be correct, but it's more likely to have bugs. But because the bug was not in 00:18:19.480 --> 00:18:22.160 the master branch, nobody testing the master branch would have noticed. It's only 00:18:22.160 --> 00:18:25.860 people testing the release branch, and that might be a much smaller group of 00:18:25.860 --> 00:18:26.620 people in practice. 00:18:27.490 --> 00:18:27.810 Right. 00:18:28.250 --> 00:18:31.590 And also, like we described, it's not the easiest thing to trip on. But if you do 00:18:31.590 --> 00:18:34.790 trip on it, it's very painful, so it was definitely worth fixing. 00:18:35.760 --> 00:18:41.120 Right. Okay. Well, there you have it. That's why the new release is Bitcoin Core 00:18:41.120 --> 00:18:47.120 24.0.1 instead of just Bitcoin Core 24. You are enlightened, our 00:18:47.120 --> 00:18:47.580 dear listener. 00:18:47.920 --> 00:18:51.160 Yes, there's two other bugs in there too, but they're less important and in very 00:18:51.160 --> 00:18:51.700 different areas. 00:18:52.760 --> 00:18:56.760 Oh, that's kind of a depressing note to close the episode on. 00:18:56.760 --> 00:19:01.780 There's always bugs. So what happens is after a release, the 00:19:01.780 --> 00:19:07.760 developers pile up existing bug fixes. For a future release. So 00:19:07.760 --> 00:19:12.420 there'll be a version 25.0, which will have the new master branch on it, but 00:19:12.420 --> 00:19:18.280 there'll also be a version 24.1, 24.2, which will have only sort of bugs, bug 00:19:18.280 --> 00:19:21.320 fixes in it that are important enough to put on the old releases. 00:19:22.400 --> 00:19:27.620 Wait, wait, wait, wait. Are there still bugs in Bitcoin Core 24.0.1 as far as we 00:19:27.620 --> 00:19:28.220 know right now? 00:19:28.360 --> 00:19:28.840 I don't know. 00:19:29.260 --> 00:19:31.620 I thought that's what you said, but maybe I misheard. 00:19:31.800 --> 00:19:35.620 No, the general process is that we'll collect bug fixes over time. So maybe 00:19:35.620 --> 00:19:38.960 immediately after a release, there is no known bug. Or maybe there's a known bug, 00:19:38.960 --> 00:19:44.260 but there's no fix for it yet. But then over time, say the next six months or a 00:19:44.260 --> 00:19:48.540 year, bugs will get fixed. We'll find out there were bugs in version 24. And then 00:19:48.540 --> 00:19:51.910 you can do two things to your users. You can say, well, tough, just download 00:19:51.910 --> 00:19:56.130 version 25 if you want that bug fixed. But then they have to download all these 00:19:56.130 --> 00:20:01.620 new changes in version 25, which people don't like. So there will also be version 00:20:01.620 --> 00:20:06.480 24.1, which only fixes the bugs, but doesn't have any of the other new changes. 00:20:06.960 --> 00:20:08.120 That's called backporting. 00:20:08.620 --> 00:20:14.120 Sjors, I just want you to tell our listeners that Bitcoin Core 24.0.1 is squeaky 00:20:14.120 --> 00:20:19.120 clean and we're ready for the new year. We're ready for Bitcoin Core. No, we're 00:20:19.120 --> 00:20:22.800 ready for 2023 with Bitcoin Core 24.0.1. 00:20:23.020 --> 00:20:28.340 Well, all I can tell you is that currently there's a milestone called 24.1 and it 00:20:28.340 --> 00:20:29.360 doesn't have any bugs in it. 00:20:29.840 --> 00:20:33.900 There we go. End of the episode. Thank you for listening to Bitcoin, 00:20:33.900 --> 00:20:35.740 Explained.