WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:08.620 --> 00:00:13.060 Live from Oranjestad, Aruba, and Utrecht, the Netherlands, this is the 00:00:13.060 --> 00:00:15.240 Van Wirdum Sjorsnado. Hello. 00:00:15.800 --> 00:00:21.760 Welcome. And listeners, sorry for the maybe not perfect sound quality, because we 00:00:21.760 --> 00:00:23.720 have to make do with the remote recording. 00:00:24.390 --> 00:00:29.590 Yeah, for the second time since we're making our show, my laptop broke, so here I 00:00:29.590 --> 00:00:30.370 am on my phone. 00:00:31.840 --> 00:00:36.260 And you decided to use your laptop in a swimming pool, which you know you should not do. 00:00:37.980 --> 00:00:44.270 No one told me that I shouldn't do that. Okay. Apparently, my laptop is not waterproof. 00:00:46.430 --> 00:00:49.990 Sjors. Today, we are going to discuss the exotic 00:00:49.990 --> 00:00:56.150 CVE-2021-31876. 00:00:57.310 --> 00:00:58.850 Cool. Is that a spaceship? 00:00:59.150 --> 00:01:02.890 That sounds exciting, right? It is apparently a bug. 00:01:04.020 --> 00:01:04.200 Ooh. 00:01:06.340 --> 00:01:11.550 This is actually what I'm going to ask you, Sjors. Sjors, CVE, what is a CVE 00:01:11.550 --> 00:01:13.570 number? What are we talking about here? 00:01:14.710 --> 00:01:19.830 Oh, it stands for Common Vulnerabilities and Exposures. It's basically, 00:01:20.090 --> 00:01:25.810 there's just a big open database of known bugs, security 00:01:25.810 --> 00:01:30.730 vulnerabilities really, not all bugs. Across all types of software. 00:01:31.540 --> 00:01:37.540 Pretty much, yeah. So then it starts with the year and then some number that 00:01:37.540 --> 00:01:38.040 indicates, 00:01:39.320 --> 00:01:45.150 you know, the number, which bug it was in that year. And 00:01:45.150 --> 00:01:49.470 pretty much anybody can file such a report and say, hey, I think we found a 00:01:49.470 --> 00:01:54.650 security vulnerability in this project. And then you can decide how long you want 00:01:54.650 --> 00:01:59.040 to keep it secret because you want to give people time to fix things. And then it 00:01:59.040 --> 00:02:01.340 becomes for everybody to see and refer to. 00:02:01.780 --> 00:02:06.940 So this was basically bug number 31876. 00:02:08.140 --> 00:02:13.260 That's the number. This is a bug in Bitcoin Core, right? Yes. 00:02:15.530 --> 00:02:20.690 So, obviously, to be clear, not all CVE bugs are in Bitcoin Core, but this one 00:02:20.690 --> 00:02:24.510 is, and that's what we're discussing today. So, Sjors. 00:02:26.560 --> 00:02:32.360 This bug was discovered in March of this year by Antoine Riard, 00:02:32.560 --> 00:02:34.400 if I'm pronouncing that correctly. 00:02:34.400 --> 00:02:35.400 No, you have to ask him. 00:02:37.990 --> 00:02:43.630 And it was disclosed about two weeks ago on the Bitcoin dev development list. 00:02:45.070 --> 00:02:46.670 So what is this bug? 00:02:46.870 --> 00:02:51.550 Yeah, so it relates to an episode we talked about earlier, replaced by fee, RBF. 00:02:52.360 --> 00:02:57.410 And the idea there is, you know, if you make a transaction, then 00:02:57.410 --> 00:03:01.650 maybe the fees go up and you want to increase the fee for that transaction 00:03:01.650 --> 00:03:06.000 because it's not confirmed yet. And you can use replaced by fee to indicate that 00:03:06.000 --> 00:03:06.640 you want to do that. 00:03:08.190 --> 00:03:13.030 Yeah, so users are sending transactions to the network all the time, anytime 00:03:13.030 --> 00:03:17.190 they're spending money. And all of these transactions end up in people's 00:03:17.190 --> 00:03:21.530 mempools, including miners' mempools. And then miners, when they create a new 00:03:21.530 --> 00:03:26.470 block, they basically include all the transactions that pay the highest fee until 00:03:26.470 --> 00:03:31.390 the block is full, essentially. Which means that if you're paying a low fee, you 00:03:31.390 --> 00:03:35.730 might have to wait until the next block. Or if you paid a very low fee, you might 00:03:35.730 --> 00:03:41.610 have to wait for a very long time. So it could happen that you know after 00:03:42.030 --> 00:03:45.910 you send the transaction then all of a sudden there's a lot more transactions on 00:03:45.910 --> 00:03:50.530 the network paying more fees and you're waiting longer than you plan to wait for 00:03:50.530 --> 00:03:55.900 your transaction to confirm and if you include an RBF replace by fee flag in the 00:03:55.900 --> 00:04:00.700 transaction that allows you to increase the fee before it's confirmed, which will 00:04:00.700 --> 00:04:01.960 make it confirmed faster. 00:04:01.330 --> 00:04:06.180 That’s right. And it should be noted that this is not a consensus rule. So it is 00:04:06.180 --> 00:04:09.620 not because it's not happening in the blockchain itself. It's happening on the 00:04:09.620 --> 00:04:15.400 network. And on the network, people can run whatever software they want. So this 00:04:15.400 --> 00:04:19.780 isn't a guarantee, but it's basically a convention to make it easier to replace 00:04:19.780 --> 00:04:25.640 your transaction, while also having some security that people can't if they 00:04:25.640 --> 00:04:30.180 don't want to. But we had a whole episode dedicated to that. But one of the 00:04:30.180 --> 00:04:34.940 important aspects of this scheme is what happens if you have two transactions 00:04:34.940 --> 00:04:40.880 that build on top of each other? What if one of them signals that it 00:04:40.880 --> 00:04:46.120 can be replaced, but then the child of that transaction says it cannot be 00:04:46.120 --> 00:04:49.620 replaced? And this is where the bug comes in. 00:04:49.700 --> 00:04:55.120 Yeah, so you're sending funds to me, and then I'm sending the same funds, 00:04:55.120 --> 00:04:58.420 essentially, to Ruben before the transaction is confirmed? 00:04:58.860 --> 00:05:00.500 Yeah, and because... 00:05:00.500 --> 00:05:05.640 My transaction to Ruben is what's considered a child transaction, and your 00:05:05.640 --> 00:05:08.460 transaction to me, the first one, is the parent transaction, right? 00:05:08.840 --> 00:05:13.520 Yeah, and that means that if I put a flag in my transaction to you that says this 00:05:13.520 --> 00:05:19.150 can be replaced, then by definition, your transaction can also be replaced, 00:05:19.150 --> 00:05:21.230 even if you don't indicate it. 00:05:21.550 --> 00:05:25.770 So now we know what the parent transaction is and what the child transaction is. 00:05:25.910 --> 00:05:28.850 So let's get to what the actual bug is in this context. 00:05:30.510 --> 00:05:34.790 Right. So the official rule, as it's indicated in the BIP, the Bitcoin 00:05:34.790 --> 00:05:40.670 Improvement Protocol, is that if the parent transaction signals RBF, 00:05:40.910 --> 00:05:44.510 then the child transaction should also be RBF. 00:05:44.910 --> 00:05:45.350 Right. 00:05:45.610 --> 00:05:49.410 So in other words, if I indicated that I can replace the transaction, then that 00:05:49.410 --> 00:05:54.230 means you can also change the transaction. And the bug, and that's what comes in, 00:05:54.310 --> 00:05:56.130 is that for Bitcoin Core, that's not the case. 00:05:56.290 --> 00:06:01.090 So I can increase the fee of my transaction to Ruben if 00:06:01.090 --> 00:06:06.190 your transaction to me was an RBF transaction, even if my transaction wasn't 00:06:06.190 --> 00:06:09.030 necessarily an RBF transaction. I can still increase the fee, right? 00:06:10.540 --> 00:06:12.700 Yes, exactly. Except you can't. 00:06:12.720 --> 00:06:17.020 That's the official rule. And now the bug is that it turns out that that's not 00:06:17.020 --> 00:06:19.400 actually what's in the Bitcoin Core code, correct? 00:06:19.880 --> 00:06:23.320 Yeah, exactly. The Bitcoin Core code is not checking that rule. 00:06:23.460 --> 00:06:28.730 Right, so this is a bug specifically for the Bitcoin Core 00:06:28.730 --> 00:06:31.370 client, essentially. Is that the right way to put it? 00:06:31.740 --> 00:06:32.280 Yes. 00:06:32.760 --> 00:06:36.930 Right. So first of all, is this a problem? What kind of what are we looking at 00:06:36.930 --> 00:06:41.070 here? Is this something that we need to be concerned about just, on on face at 00:06:41.070 --> 00:06:41.730 face value? 00:06:42.220 --> 00:06:48.040 So at first sight, you might think it's not really a problem because if you 00:06:48.040 --> 00:06:51.840 wanted to be able to use RBF, you know, in your transaction to Ruben, you could 00:06:51.840 --> 00:06:57.020 have just signaled RBF. So it only becomes a problem in more complicated 00:06:57.020 --> 00:06:57.780 scenarios, 00:06:58.980 --> 00:07:04.920 especially if you have multi-party systems like Lightning and other second layer 00:07:04.920 --> 00:07:10.220 kind of ideas, where there's two parties involved that can spend a certain 00:07:10.220 --> 00:07:15.590 transaction. So you know so for example yeah if there's two parties involved that 00:07:15.590 --> 00:07:20.410 can spend the same output then those two parties, they might be able to replace 00:07:20.410 --> 00:07:24.080 each other's transactions, and then this thing can get messy. 00:07:24.480 --> 00:07:29.680 Yeah, so from what I understand, this is… it's a bit… it's a bug in the Bitcoin 00:07:29.680 --> 00:07:35.680 Core code, but really the only part of the Bitcoin ecosystem 00:07:35.680 --> 00:07:39.820 that seems to be affected right now is the Lightning Network, the Lightning 00:07:39.820 --> 00:07:45.670 Protocol. And that's where it gets a little bit complicated, right? So 00:07:45.670 --> 00:07:46.470 can you... 00:07:46.470 --> 00:07:48.310 Yeah, a little bit just to put it mildly. 00:07:48.270 --> 00:07:54.260 So maybe, yes, maybe you can try a hand at explaining how… How 00:07:54.260 --> 00:07:57.120 can someone exploit this bug on Lightning? 00:07:57.740 --> 00:08:03.540 Yeah, so for that, we need to explain very roughly what an HTLC is, a hash 00:08:03.540 --> 00:08:05.100 time lock contract. 00:08:06.310 --> 00:08:10.870 And this is when in Lightning you are sending, or not just in Lightning, it's a 00:08:10.870 --> 00:08:13.490 general mechanism, but in Lightning is what we're talking about here… 00:08:13.490 --> 00:08:19.420 is… let’s say, well, let's talk about Alice, Bob, and Carol, so it's a 00:08:19.420 --> 00:08:24.150 bit easy to remember the direction. Let's say Alice is sending one Bitcoin to 00:08:24.150 --> 00:08:29.460 Carol through Bob. And so these, so Alice has a channel with Bob and Bob has a 00:08:29.460 --> 00:08:35.210 channel with Carol. And the way Lightning lets you safely move one 00:08:35.210 --> 00:08:40.720 Bitcoin from Alice to Carol is by Alice sending it to Bob and by Bob sending it 00:08:40.720 --> 00:08:45.680 to Carol. But this is done atomically. So that means that the way Lightning is 00:08:45.680 --> 00:08:51.580 designed is Alice will only send money to Bob if Bob also sends money to Carol, 00:08:51.820 --> 00:08:55.000 and otherwise nothing happens. So this way you don't end up with a situation 00:08:55.000 --> 00:08:58.940 where Bob is sending money to Carol, but Alice is not sending money to Bob 00:08:58.940 --> 00:09:00.880 because then Bob is very unhappy. 00:09:01.440 --> 00:09:06.040 Yeah, essentially Carol creates a secret. I think that's the way it works, right? 00:09:06.240 --> 00:09:10.860 Carol creates a secret number and then gives the hash to Alice. 00:09:12.030 --> 00:09:17.190 And Alice sort of tells Bob, if you tell me 00:09:17.190 --> 00:09:23.130 the secrets that refers to this hash, then I'll give you a Bitcoin. And 00:09:23.130 --> 00:09:28.990 then Bob can tell Carol the same thing. Bob also tells Carol, if you can 00:09:28.990 --> 00:09:33.230 tell me the secrets of this hash, then you'll get a Bitcoin. And the way this 00:09:33.230 --> 00:09:38.690 actually works is that there are transactions created that send 00:09:39.110 --> 00:09:45.040 coins from Bob to Carol and from Alice to Bob that 00:09:45.780 --> 00:09:50.940 require this secret. So if… am I saying this right? If… 00:09:52.090 --> 00:09:57.910 let's say, if Bob publishes... Hang on. Who's publishing 00:09:57.910 --> 00:09:59.130 what? Help me out here. 00:10:00.530 --> 00:10:06.200 Yeah, so, it basically goes back from from Carol to to Alice back. So 00:10:06.200 --> 00:10:07.800 Carol publishes the secret. 00:10:09.390 --> 00:10:15.320 Then… So Bob, let me do this again. Bob has a transaction that says Carol gets my 00:10:15.320 --> 00:10:16.920 Bitcoin if she reveals the secret. 00:10:19.180 --> 00:10:23.480 Right? So what happens then is that Carol reveals the secret and Bob sends the money. 00:10:25.220 --> 00:10:25.660 Yeah. 00:10:25.780 --> 00:10:30.780 And because the secret is revealed, in this case on the blockchain, Alice can see 00:10:30.780 --> 00:10:36.180 the secret. So Alice can now take the money. Okay. Alice can now send the money. 00:10:36.420 --> 00:10:41.420 No, no, no, no, no, no, no, no. Bob sees the secret and therefore… He can claim 00:10:41.420 --> 00:10:42.700 the money from Alice, right? 00:10:42.900 --> 00:10:47.140 Oh, yeah, exactly. Well, yeah, Alice could also be nice and volunteer the money, 00:10:47.240 --> 00:10:52.820 but yeah, this is how it works, right? Bob wants the money, so Bob sees the 00:10:52.820 --> 00:10:57.360 secret that Carol published, takes the money from Alice, and Carol is able to 00:10:57.360 --> 00:11:00.220 take the money from Bob. So this is all good. Exactly. 00:11:01.700 --> 00:11:06.100 And the thing is, though, there's also a condition where there could be a 00:11:06.100 --> 00:11:11.150 timeout. So if nobody reveals a secret, well, you don't want those coins to be 00:11:11.150 --> 00:11:16.270 stuck forever. So basically, if nothing happens, then after a while, Alice can 00:11:16.270 --> 00:11:17.270 just take the money back. 00:11:18.890 --> 00:11:23.120 And if nothing happens after a while, Bob can take the money back. Right? That's 00:11:23.120 --> 00:11:26.260 a fallback mechanism. There's a time out there. Does that still make sense? 00:11:26.620 --> 00:11:29.340 All right. So that's what HTLCs are. 00:11:30.980 --> 00:11:35.580 Let's get to this bug. How does this… how can this bug be exploited in the 00:11:35.580 --> 00:11:36.660 context of HTLC? 00:11:36.960 --> 00:11:42.000 Yeah, so the way you kind of have to understand how it was designed is that if 00:11:42.000 --> 00:11:47.980 Carol is nice and on time, she will reveal the secret on the blockchain, 00:11:49.010 --> 00:11:49.530 right? 00:11:52.800 --> 00:11:58.000 Sorry, one second. She will reveal the secret on the blockchain, which is just a 00:11:58.000 --> 00:12:01.460 transaction, and that transaction confirms because that's what the blockchain does. 00:12:03.530 --> 00:12:08.810 And that means that the timeout, the alternative transaction where she can take 00:12:08.810 --> 00:12:14.600 the money back, well, that can't go anywhere because once the 00:12:14.600 --> 00:12:18.700 secret is revealed and that transaction is confirmed, the transaction timeout 00:12:18.700 --> 00:12:22.300 cannot be there. You would need to reorg the blockchain to be able to use it. 00:12:22.670 --> 00:12:23.630 Does that still make sense? 00:12:23.930 --> 00:12:29.010 Yeah. In the context of Lightning, it doesn't only matter who's paying who. It 00:12:29.010 --> 00:12:33.450 also matters that the transaction confirms in time. Because if the transaction 00:12:33.450 --> 00:12:38.990 doesn't confirm in time, the payer can take the money back through the 00:12:38.990 --> 00:12:41.010 timeout. So that's why that matters. 00:12:41.270 --> 00:12:44.730 So if nothing happens on the blockchain, then after 80 blocks, the timeout 00:12:44.730 --> 00:12:50.270 transaction can be spent. But if before that moment the secret is revealed, then 00:12:50.270 --> 00:12:54.310 that transaction, then the timeout transaction cannot be spent because, yeah, it 00:12:54.310 --> 00:12:58.610 would replace the other one. So that's how it works in theory. But the problem is 00:12:58.610 --> 00:13:04.360 it has to go into the mempool first. And so what Carol can do if she's 00:13:04.360 --> 00:13:08.620 kind of collaborating with Alice, I think, although I'm not sure about that part, 00:13:08.960 --> 00:13:14.220 what she can do is she can release the transaction with the secret in it. 00:13:15.280 --> 00:13:21.250 But she puts a very low fee on it. And now we 00:13:21.250 --> 00:13:26.380 have a problem. Because this transaction is in the mempool. It is 00:13:26.380 --> 00:13:30.740 revealing the secret. It is claiming the funds. But it's not getting confirmed. 00:13:31.080 --> 00:13:36.280 And it can take a long time. In fact, it can take so long that in the meantime, 00:13:36.600 --> 00:13:39.280 there's a timeout even for Alice. 00:13:40.520 --> 00:13:46.490 And so Alice will just issue her refund transaction. And so now 00:13:46.490 --> 00:13:51.520 what happens is Alice got her money back and Carol still hasn't paid. 00:13:51.720 --> 00:13:54.140 Okay, Sjors, I think you just explained it the wrong way around. 00:13:54.140 --> 00:13:56.700 Yeah, that's possible. We're not sure. We just listened to it. 00:13:56.640 --> 00:14:01.680 So what… so what… so what… I… what… what… happens is Carol publishes the 00:14:01.680 --> 00:14:07.460 transaction to claim the funds. And she actually claims the funds. Now 00:14:07.460 --> 00:14:13.460 the secret is revealed to Bob who can also claim the funds 00:14:13.460 --> 00:14:19.100 from Alice. But if this transaction is low on the second transaction 00:14:19.100 --> 00:14:23.980 where Bob claims the funds, then it's possible that this transaction won't 00:14:23.980 --> 00:14:29.700 confirm and Alice can later reclaim the funds when the timeout has run out. 00:14:29.940 --> 00:14:33.960 And now Bob is stuck in the middle without any money because the funds have been 00:14:33.960 --> 00:14:39.600 claimed from him and he's not actually able to claim any funds back from Alice 00:14:39.600 --> 00:14:44.240 because Alice basically canceled that transaction. I think that's what happened. 00:14:44.240 --> 00:14:46.160 That's the… that's the exploit, right? 00:14:46.160 --> 00:14:50.690 I think, yeah, I think so. Let me also say it in one way, right? So Alice 00:14:50.690 --> 00:14:55.050 basically just claimed the money because she knew the secret, right? Because the 00:14:55.050 --> 00:14:55.950 secret was revealed. 00:14:56.390 --> 00:14:56.850 Yep. 00:14:57.630 --> 00:15:00.410 And she used a normal fee, so that transaction will confirm. 00:15:03.150 --> 00:15:03.570 Nope. 00:15:03.850 --> 00:15:08.920 No, no, no. Sorry. See, this is really confusing. No, what Alice does is she 00:15:08.920 --> 00:15:14.010 just… um… she can wait, right? She has to take the initiative. So she basically 00:15:14.010 --> 00:15:17.470 issued the refund to take the money back because there was a timeout. 00:15:17.890 --> 00:15:21.070 Yeah, Alice has all the time in the world, basically. Well, Alice is sort of 00:15:21.070 --> 00:15:25.180 hoping that the transaction won't confirm so she can claim it back. Alice is the 00:15:25.180 --> 00:15:29.990 [unclear]… Alice is ultimately the [unclear] the one paying Carol. So if she can 00:15:29.990 --> 00:15:35.590 claim the funds back, then... Bob is screwed if he already paid 00:15:35.590 --> 00:15:38.670 Carol. I think that's sort of the problem here. 00:15:39.610 --> 00:15:41.230 Yeah. So, indeed. 00:15:42.130 --> 00:15:47.190 Dear Van Wirdum Sjorsnado listeners, we're sorry for this confusing episode. It 00:15:47.190 --> 00:15:51.830 doesn't help that we're doing it at the distance. We're kind of figuring it out 00:15:51.830 --> 00:15:56.510 ourselves, admittedly, but we're pretty sure this is the problem. Right, Sjors? 00:15:57.210 --> 00:16:00.710 Yeah, roughly anyway. Because whenever you read these mailing lists posts, it 00:16:00.710 --> 00:16:04.130 always turns out to be one more step more complicated. But I think this is the 00:16:04.130 --> 00:16:09.050 basic principle, where we have a transaction that is in the mempool, but it's not 00:16:09.050 --> 00:16:12.830 going to confirm on time, and therefore there's another timeout, and this allows 00:16:12.830 --> 00:16:18.070 people to cheat. And normally the way to prevent that kind of problem, or to deal 00:16:18.070 --> 00:16:20.990 with that kind of problem, is with RBF. 00:16:22.220 --> 00:16:27.180 Yes, let's just get to the heart of the problem here. The problem indeed is that 00:16:27.180 --> 00:16:32.280 usually you're able to RBF your transaction, which is important in the context of 00:16:32.280 --> 00:16:35.160 Lightning where we have timeout type of stuff going on. 00:16:35.360 --> 00:16:35.500 Yeah. 00:16:35.720 --> 00:16:40.220 So if all of a sudden you can't use RBF anymore because there's a bug in Bitcoin 00:16:40.220 --> 00:16:42.340 Core, now it's getting… 00:16:43.650 --> 00:16:48.150 more problematic than usual, where usually you can just have patience. It just 00:16:48.150 --> 00:16:51.610 means your transaction is being a bit slower. Now, all of a sudden, there's a 00:16:51.610 --> 00:16:56.490 real problem because someone can take your money back if you can't RBF. 00:16:56.590 --> 00:16:57.730 Right, because normally... 00:16:57.730 --> 00:16:58.630 That's the gist of the problem. 00:16:58.850 --> 00:17:02.950 Yeah, because what Bob would have wanted to do in this case is… 00:17:04.520 --> 00:17:09.120 basically get his refund because he would say he's not actually, you know, he can 00:17:09.120 --> 00:17:12.820 see that Alice is getting the refund, so he should be getting the refund. And he 00:17:12.820 --> 00:17:16.680 would be able to do that because the refund would just pay a higher fee than the 00:17:16.680 --> 00:17:19.220 other transaction and all would be happy. 00:17:21.160 --> 00:17:27.160 But basically, because of this RBF glitch here, it might not be 00:17:27.160 --> 00:17:27.620 that easy. 00:17:28.200 --> 00:17:33.100 Okay, well, full disclosure, I'm not sure if we explained it right. I'm sure we 00:17:33.100 --> 00:17:38.920 explained the bug right. I'm sure we explained the ultimate problem right. I'm 00:17:38.920 --> 00:17:42.840 not sure if we explained the HLC order of things right. 00:17:43.280 --> 00:17:46.180 I think that's correct that we explained it probably wrong. 00:17:46.360 --> 00:17:51.300 If we got it wrong, I'm sorry, everyone. Better next time, especially if we're 00:17:51.300 --> 00:17:52.800 live in the same room again. 00:17:54.140 --> 00:17:58.420 I hope you got something out of it. Sjors, last part of the episode then… Is 00:17:58.420 --> 00:18:01.860 there something… how worried should we be… how worried should Lightning people 00:18:01.860 --> 00:18:03.820 be? And is this something fixable? 00:18:04.320 --> 00:18:09.400 I'm not entirely sure how worried Lightning people should be because this type of 00:18:09.400 --> 00:18:13.380 attack was already possible even without this bug, but it was more complicated. 00:18:14.020 --> 00:18:19.880 And at the same time, Lightning has been developing other solutions 00:18:19.880 --> 00:18:25.790 around this general problem. So honestly, I don't really know. But the 00:18:25.790 --> 00:18:31.130 best news here is that this bug is fairly easy to fix. Or at least, you know, it 00:18:31.130 --> 00:18:35.550 can be fixed because, again, it's not a consensus rule. So Bitcoin Core could 00:18:35.550 --> 00:18:40.550 simply ship a fix for it. And then when people upgrade, the fix is there. 00:18:41.160 --> 00:18:45.460 And this also [unclear] that ignore RBF completely, which means still replace 00:18:45.460 --> 00:18:46.520 whatever has a higher fee. 00:18:47.430 --> 00:18:51.730 Yeah, it shouldn't be a controversial fix, of course. Is it already fixed as far as you know? 00:18:52.410 --> 00:18:57.270 As far as I know, I don't think so. I haven't checked in a few days. 00:18:58.070 --> 00:19:02.610 Somebody wrote a test, a functional test for Bitcoin Core to describe the bug. 00:19:03.050 --> 00:19:05.490 That's always nice because then it's easier to see that it's fixed. 00:19:07.140 --> 00:19:09.660 But I don't know how easy or hard it is to fix it. 00:19:11.750 --> 00:19:16.350 But in principle, I don't think it would be controversial to fix it. I mean, it 00:19:16.350 --> 00:19:20.910 would be good for Bitcoin Core to do what the BIP says it should do. And we know 00:19:20.910 --> 00:19:25.370 that I think in btcd, which is another implementation, it is implemented 00:19:25.370 --> 00:19:25.810 correctly. 00:19:26.330 --> 00:19:30.300 All right. Sjors, I think this was our worst episode so far. What do you think? 00:19:30.580 --> 00:19:34.380 I don't think so. We have the pilot episode that we never actually released. 00:19:34.580 --> 00:19:37.920 Oh, yeah, that’s definitely the worst one. 00:19:35.330 --> 00:19:35.930 Far worse. 00:19:38.040 --> 00:19:41.480 Well, this is maybe the worst one we're actually going to put online. 00:19:42.280 --> 00:19:45.980 Well, hopefully it's enough for people to dig into this rabbit hole and actually 00:19:45.980 --> 00:19:46.640 understand it. 00:19:46.860 --> 00:19:47.860 Better luck next time. 00:19:48.020 --> 00:19:48.500 All right, then. 00:19:48.620 --> 00:19:51.040 But I think that was the episode for us. 00:19:51.180 --> 00:19:54.800 Yes. Well, thank you for listening to the Van Wirdum Sjorsnado. 00:19:55.330 --> 00:19:59.410 Sjors, maybe we should compensate with a good pun. Do you have a good pun to 00:19:59.410 --> 00:20:00.330 compensate it with? 00:20:00.850 --> 00:20:01.330 No. 00:20:03.130 --> 00:20:05.110 All right, then we'll end without a pun. 00:20:05.350 --> 00:20:07.870 Sorry about that. All right, until next time. 00:20:08.450 --> 00:20:09.250 There you go.