WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.660 --> 00:00:22.880 Live from Utrecht, this is Bitcoin. 00:00:23.720 --> 00:00:24.120 Explained. 00:00:24.380 --> 00:00:24.820 Hey Sjors. 00:00:25.040 --> 00:00:25.460 What's up? 00:00:26.210 --> 00:00:26.870 I'm good. 00:00:27.750 --> 00:00:28.730 How do you like the weather? 00:00:29.030 --> 00:00:34.270 Yeah, well, it was too hot all summer. And then it was nice for about a week. 00:00:34.790 --> 00:00:36.370 And now we're back to too cold. 00:00:36.770 --> 00:00:38.610 So this is going to be a great winter. 00:00:39.440 --> 00:00:43.680 That's that's winter for you at least for now it's still a little bit light for 00:00:43.680 --> 00:00:47.460 example while we're recording it's still light and it's past six that's that's 00:00:47.460 --> 00:00:51.680 the really dreadful moment for me when the clock changes when you go back to the 00:00:51.680 --> 00:00:54.300 we revert… 00:00:54.300 --> 00:01:00.200 Yeah we go to standard time although some people want to change it and make the 00:01:00.200 --> 00:01:02.560 summertime the default which I think is terrible but… 00:01:03.450 --> 00:01:08.650 I would definitely prefer that just because I don't get up that early anyways. So 00:01:08.650 --> 00:01:11.930 I like to optimize my sun hours. 00:01:12.970 --> 00:01:16.800 I mean, ultimately, you can just get up whenever you want to get up, right? 00:01:17.970 --> 00:01:19.770 Unless you have to be in a physical place. 00:01:19.790 --> 00:01:23.870 But you're kind of reliant on the rest of society around you, right? Like stores 00:01:23.870 --> 00:01:28.550 close at a certain time and people get out of work at a certain time. Like might 00:01:28.550 --> 00:01:31.910 be your friends or you want to record a podcast at a certain time because you 00:01:31.910 --> 00:01:35.490 want to eat at a certain time. So I don't have that full flexibility that you 00:01:35.490 --> 00:01:41.120 suggest because of all these people around me okay Sjors, so I'm gonna shill the 00:01:41.120 --> 00:01:44.520 conference one more time conference is coming up okay you can get a 10 discount 00:01:44.520 --> 00:01:50.380 if you know how to spell Sjorsnado that's your discount code Sjorsnado 00:01:50.380 --> 00:01:56.380 on I think it's b.tc slash amsterdam I think that's the that's the 00:01:56.380 --> 00:02:02.320 website for the conference all right Sjors, we're gonna discuss The 00:02:02.320 --> 00:02:06.320 new Bitcoin Core release that's coming up. It's not here yet. It's Bitcoin Core 00:02:06.320 --> 00:02:07.940 24.0. 00:02:09.240 --> 00:02:14.400 24.0 that's the upcoming one real quick for maybe there are some new listeners 00:02:14.400 --> 00:02:17.760 what does it mean that there's a new Bitcoin Core release coming out? 00:02:17.760 --> 00:02:23.240 Yeah so because Bitcoin Core does not have a roadmap or anything like that there 00:02:23.240 --> 00:02:27.780 is just a new release every six months or so and things that are ready go into 00:02:27.780 --> 00:02:31.540 that new release and things that are not ready may go into another release so 00:02:31.540 --> 00:02:33.760 there's nothing very special about these releases. 00:02:34.880 --> 00:02:38.940 Right. And so it's time for number 24. It's just an update that happens twice a 00:02:38.940 --> 00:02:40.620 year. Generally, whatever is done is done. 00:02:41.060 --> 00:02:44.020 Yes. And then there are some minor updates throughout the rest of the year that 00:02:44.020 --> 00:02:49.860 might be 24.1, 24.2, et cetera. And those typically are just bug fixes, but no 00:02:49.860 --> 00:02:50.520 major changes. 00:02:51.040 --> 00:02:55.820 Right. And right now, there's a release candidate. At the time of recording this 00:02:55.820 --> 00:03:00.060 podcast, there's, I think, the first release candidate for Bitcoin Core 24. What 00:03:00.060 --> 00:03:01.080 does a release candidate mean? 00:03:01.280 --> 00:03:06.160 Kind of what the word suggests. It's a candidate for the release. So if all goes 00:03:06.160 --> 00:03:12.040 well, then the actual release will be made identical to the last candidate. But 00:03:12.040 --> 00:03:15.260 the idea is that people who know what they're doing should be downloading that 00:03:15.260 --> 00:03:19.700 release candidate and or compiling it themselves and play around with it and make 00:03:19.700 --> 00:03:24.960 sure that nothing crashes, that things they use, especially if you run some sort 00:03:24.960 --> 00:03:29.600 of automated service, like you might be running an exchange or maybe you're 00:03:29.600 --> 00:03:33.550 running BTCPay or something like that. You want to make sure nothing breaks. In 00:03:33.550 --> 00:03:37.210 your setup because Bitcoin Core tries to not break things that use it but it 00:03:37.210 --> 00:03:38.210 happens occasionally. 00:03:38.790 --> 00:03:43.450 Right so if there's no report of anything breaking then this release candidate 00:03:43.450 --> 00:03:45.650 will basically be the release right? 00:03:45.870 --> 00:03:48.910 Yeah but I think there's already some some things that have been improved so 00:03:48.910 --> 00:03:50.750 there will definitely be a second release candidate. 00:03:51.010 --> 00:03:54.410 Okay yeah and I think in previous Bitcoin Core releases there were on average 00:03:54.410 --> 00:03:55.910 like four or so. 00:03:56.370 --> 00:03:57.350 Yeah I'd say that's typical. 00:03:57.640 --> 00:03:57.940 Yeah. 00:03:58.220 --> 00:04:02.360 So usually there's two weeks between them. So you release it and then maybe after 00:04:02.360 --> 00:04:05.680 a week or so people start fixing things and then after two weeks there's a new one. 00:04:06.160 --> 00:04:11.700 Right. So realistically, well, technically the new Bitcoin Core 24 release could 00:04:11.700 --> 00:04:16.200 be released any day now, but practically speaking will probably be at least a 00:04:16.200 --> 00:04:17.120 couple more weeks, right? 00:04:17.700 --> 00:04:22.740 Yeah, I'd say so. I think there is a release, attempted release schedule on the 00:04:22.740 --> 00:04:26.060 Bitcoin Core repository, which I think is for mid-October. 00:04:27.630 --> 00:04:33.580 Right. Okay. So there's a bunch of new features 00:04:33.580 --> 00:04:39.250 as well as bug fixes and improvements, sorry, performance 00:04:39.250 --> 00:04:43.630 improvements in this new release. We're going to discuss a couple of these. This 00:04:43.630 --> 00:04:49.560 is kind of just our selection. If there were, if this podcast was made 00:04:49.560 --> 00:04:55.460 by two other people. By Ors and Sharon. They might make a 00:04:55.460 --> 00:04:58.900 different selection, but we, Sjors and Aaron, we made this selection. 00:04:59.200 --> 00:05:04.680 Yeah, I mean, you can look at all the commits, so all the atomic changes that go 00:05:04.680 --> 00:05:09.060 into a release, and there could be a thousand of them, but most of them are very 00:05:09.060 --> 00:05:13.420 boring, or at least they are very boring unless you are really into details of 00:05:13.420 --> 00:05:17.660 how compilers work or into cleaning up code for the sake of cleaning it up. So 00:05:17.660 --> 00:05:20.590 there's a lot of changes that are just... not very interesting to discuss 00:05:20.590 --> 00:05:24.110 although they are important and they should be they are being you know they they 00:05:24.110 --> 00:05:28.050 always get reviewed because any of those changes could of course be a really 00:05:28.050 --> 00:05:29.650 scary thing yeah. 00:05:29.650 --> 00:05:34.710 I'm just saying we we made a selection of some of the changes that we think are 00:05:34.710 --> 00:05:38.610 probably most interesting to you our dear listener 00:05:38.610 --> 00:05:39.290 That's right. 00:05:39.290 --> 00:05:44.530 Okay so let's start Sjors, I think that this one is the first one mentioned in 00:05:44.530 --> 00:05:50.470 the release notes as well it's about the peer-to-peer and network changes is that 00:05:50.470 --> 00:05:54.830 is that a typo it should just say peer-to-peer changes peer-to-peer network 00:05:54.830 --> 00:05:55.710 changes whatever 00:05:55.710 --> 00:05:56.790 Peer-to-peer networking 00:05:56.790 --> 00:05:58.050 Yeah let's move on. 00:05:59.450 --> 00:06:05.050 So it says that there's a change and you're gonna explain to me what this is 00:06:05.050 --> 00:06:10.090 that's the format of the podcast in case you forgot it says download headers from 00:06:10.090 --> 00:06:15.390 peers so the downloading from downloading of headers from peers has been 00:06:15.390 --> 00:06:16.110 reworked 00:06:16.110 --> 00:06:16.670 That's right. 00:06:16.670 --> 00:06:17.450 Somehow okay. 00:06:18.490 --> 00:06:22.310 Yeah, this one might be worth a separate episode, but I think we can explain the 00:06:22.310 --> 00:06:26.950 gist of it now. So when your node first starts up, it is going to find peers, 00:06:27.230 --> 00:06:30.370 which we discussed in earlier episode, and then it's going to download headers 00:06:30.370 --> 00:06:34.890 from peers, which we've also discussed in earlier episodes. So it tries to get 00:06:34.890 --> 00:06:36.990 all the headers first, and then... 00:06:36.990 --> 00:06:40.970 Hang on, so every block has a header, which is essentially the hash of the block 00:06:40.970 --> 00:06:41.470 itself, right? 00:06:41.630 --> 00:06:46.340 Plus a little bit of extra info that... for example, contains the timestamp and 00:06:46.340 --> 00:06:49.460 the amount of proof of work. Well, the amount of proof of work follows in the 00:06:49.460 --> 00:06:50.860 hash, but yeah. 00:06:51.850 --> 00:06:53.870 It's basically hash plus some extra info. 00:06:54.090 --> 00:06:54.430 Yes. 00:06:55.090 --> 00:06:59.170 So it's not the whole block. Okay. So first you start downloading not the whole 00:06:59.170 --> 00:07:03.770 block or not all of the blocks, but you start downloading the headers, right? 00:07:04.050 --> 00:07:06.970 Yes, and the idea is that you first want to make sure that the chain that you're 00:07:06.970 --> 00:07:10.050 following has enough proof of work that it's even worth downloading the blocks 00:07:10.050 --> 00:07:13.510 for. Now, that's been improved many years ago. It used to be that I think it 00:07:13.510 --> 00:07:16.150 would just download headers and then some blocks and then some headers and then 00:07:16.150 --> 00:07:19.490 some blocks. And that has been changed many years ago to first download all the 00:07:19.490 --> 00:07:23.590 headers. And only then when you know for sure that you have enough proof of work 00:07:23.590 --> 00:07:27.150 because you can check that based on the headers, then you start downloading the 00:07:27.150 --> 00:07:32.370 blocks. This prevents you from wasting time chasing and basically chasing dead ends. 00:07:32.570 --> 00:07:36.870 Okay, that was already the case. So even in Bitcoin Core 23, you would already 00:07:36.870 --> 00:07:40.830 start with downloading only the headers and only later the blocks. Okay, so what 00:07:40.830 --> 00:07:41.330 has changed? 00:07:41.490 --> 00:07:45.790 So what has changed now is that we're going to download the headers twice. And 00:07:45.790 --> 00:07:50.860 that might take some explanation of why you want to do that. So there is... The 00:07:50.860 --> 00:07:55.180 potential problem that you're worried about with headers is that you could 00:07:55.180 --> 00:07:58.360 receive quite a lot of them. Because, you know, right now there have been about 00:07:58.360 --> 00:08:03.740 700,000 blocks since the genesis, but a miner could manipulate the timestamps and 00:08:03.740 --> 00:08:07.360 they could create a fake blockchain with blocks that are every second. And that 00:08:07.360 --> 00:08:09.820 would be billions and billions of... of blocks. 00:08:09.820 --> 00:08:13.960 Well I guess anyone can can only my only miner can do well anyone who can mine 00:08:13.960 --> 00:08:18.640 you you do need basically the ASIC hardware to do that 00:08:18.640 --> 00:08:22.280 Well you'd have to do the math on what kind of hardware you would need to do it I 00:08:22.280 --> 00:08:24.520 mean in principle you don't need an ASIC to mine blocks right. 00:08:24.520 --> 00:08:27.420 You need the proof of work is what I'm saying yeah you need the actual proof of work. 00:08:27.420 --> 00:08:30.740 Yeah but I mean you know the the proof of work in the beginning was quite low so 00:08:30.740 --> 00:08:33.980 you can do that with the CPU but maybe if you want to you know do some damage 00:08:33.980 --> 00:08:38.890 maybe you need more power anyway uh so the the worry is that you get billion 00:08:38.890 --> 00:08:44.030 headers from a chain and it's not the real chain but it's a lots of low work 00:08:44.030 --> 00:08:48.500 nonsense and the problem with that is that not just do you have to download it 00:08:48.500 --> 00:08:53.300 because that's kind of hard to avoid but you also tend to store it on your disk 00:08:53.300 --> 00:08:59.140 because maybe you receive half a billion headers And those don't go anywhere, 00:08:59.140 --> 00:09:01.940 but you don't know. Maybe there's another half a billion headers on top of that 00:09:01.940 --> 00:09:05.800 that do take you to the real tip. So you can't really throw those headers away 00:09:05.800 --> 00:09:10.980 that easily. And so the attack would be that lots of headers are sent to you. And 00:09:10.980 --> 00:09:14.880 that attack has been known for a long time. And the solution to that so far has 00:09:14.880 --> 00:09:15.500 been checkpoints. 00:09:16.550 --> 00:09:21.930 Okay, hang on. Let's summarize this. So first, the problem was solved. 00:09:22.490 --> 00:09:24.250 The first problem 00:09:24.250 --> 00:09:25.870 Was just getting lots of spam blocks. 00:09:26.110 --> 00:09:30.310 Yes. So that problem was solved by only checking the headers. But now, basically, 00:09:30.350 --> 00:09:35.670 a new problem is introduced. Namely, someone could just send you a boatload of 00:09:35.670 --> 00:09:37.190 fake headers, essentially. 00:09:37.530 --> 00:09:37.690 Yeah. 00:09:38.010 --> 00:09:42.170 And then while downloading all these headers, you also have to store it. This is 00:09:42.170 --> 00:09:43.010 resource intensive. 00:09:43.720 --> 00:09:46.880 Yeah, so it's basically the general category of problem is called a resource 00:09:46.880 --> 00:09:50.300 exhaustion attack. So I'm trying to exhaust one of your resources. 00:09:50.560 --> 00:09:54.040 And then you mentioned this was solved with... 00:09:54.140 --> 00:09:57.340 Checkpoints. This has been discussed very early on. That's kind of what the 00:09:57.340 --> 00:10:01.430 checkpoints are for. Fortunately... Well, checkpoints have not been added since 00:10:01.430 --> 00:10:05.410 2013 because they are, you know, not very nice way to do it. 00:10:05.590 --> 00:10:07.210 Just to be very clear, what is a checkpoint? 00:10:07.490 --> 00:10:11.150 So what a checkpoint does is it says this specific block with this hash must 00:10:11.150 --> 00:10:11.990 exist in the chain. 00:10:12.290 --> 00:10:12.710 Right. 00:10:12.890 --> 00:10:13.670 So it's not optional. 00:10:14.030 --> 00:10:14.210 Right. 00:10:14.470 --> 00:10:20.050 And that has always been done retroactively, like a long time after. So a way to 00:10:20.050 --> 00:10:24.390 abuse checkpoints is to say, well, somebody stole my coins. I'm going to now 00:10:24.390 --> 00:10:28.150 introduce a checkpoint that happened before somebody stole my coins for a new 00:10:28.150 --> 00:10:32.150 block that I've created that does not steal my coins. And then, you know, we 00:10:32.150 --> 00:10:34.450 start history again. That's the worst case. 00:10:34.450 --> 00:10:36.130 That should be after someone. 00:10:37.520 --> 00:10:38.940 So somebody steals my coins. 00:10:39.080 --> 00:10:39.200 Yeah. 00:10:39.800 --> 00:10:43.960 Let's say that happens today. Then I call up a miner and say, could you make a 00:10:43.960 --> 00:10:47.660 couple of new blocks that don't steal my coins? Here's the double spend version 00:10:47.660 --> 00:10:51.500 that I want to include in that block. They mine it for me. And then I release a 00:10:51.500 --> 00:10:55.840 new version of Bitcoin Core that says, here's a checkpoint. You must ignore the 00:10:55.840 --> 00:10:59.460 real big chain that has built on top of the hack and actually go for this other chain. 00:10:59.540 --> 00:11:04.000 Yeah, so with the checkpoint, you can sort of overrule the longest chain rule. 00:11:04.200 --> 00:11:09.760 That's right. And that has been done in many altcoins. So the concern is that we 00:11:09.760 --> 00:11:14.040 don't want that to happen in Bitcoin. So one way to prevent that, I think, has 00:11:14.040 --> 00:11:17.740 been from the beginning to introduce the checkpoints only much after they've 00:11:17.740 --> 00:11:20.340 already happened. So you already know they're part of the longest chain. 00:11:20.440 --> 00:11:24.060 Everybody can verify that. And the checkpoint is buried quite deeply. But it's 00:11:24.060 --> 00:11:28.060 still not a very pretty solution. And so people stopped doing it. So it'd be 00:11:28.060 --> 00:11:29.260 nice, but it'd be very nice. 00:11:29.280 --> 00:11:31.240 Did you mention when the last checkpoint was? 00:11:31.320 --> 00:11:32.080 I think it was 2013. 00:11:32.480 --> 00:11:32.680 Right. 00:11:33.000 --> 00:11:34.180 It's quite a long time ago. 00:11:34.520 --> 00:11:35.080 It's a while, yeah. 00:11:35.280 --> 00:11:39.020 Yeah. And so it'd be nice to get rid of those things entirely because, you know, 00:11:39.080 --> 00:11:44.420 they are confusing. And, you know, we probably don't want to add new ones. So 00:11:44.420 --> 00:11:49.660 in order to get rid of them, you still need to fix this resource exhaustion 00:11:49.660 --> 00:11:54.400 attack that we just talked about. So then how do you do that? Well, the trick is 00:11:54.400 --> 00:11:58.840 to download headers twice, as I said. So what you do is you download them once. 00:11:59.440 --> 00:12:03.430 And when you download them once, you don't save them. You just... Look at them, 00:12:03.550 --> 00:12:06.590 check if they're correct, and you throw them away. So this means it does not use 00:12:06.590 --> 00:12:11.550 any of your disk space. And then if you see enough work at the end, if you 00:12:11.550 --> 00:12:14.690 checked all the headers and you see the proof of work is enough, it's the longest 00:12:14.690 --> 00:12:19.450 chain, then you ask the peer, hey, can you send them again, please? And you 00:12:19.450 --> 00:12:20.090 download them again. 00:12:21.000 --> 00:12:24.940 Right. Yeah. I think I mentioned yesterday when we went over this in our 00:12:24.940 --> 00:12:28.540 preparation, this is kind of how my attention span usually works. 00:12:28.780 --> 00:12:32.460 Exactly. You first let me ramble on a bit and then you think, oh, this might 00:12:32.460 --> 00:12:35.140 actually be interesting. And then you say, what did you say again? Please repeat. 00:12:35.180 --> 00:12:36.100 Can you repeat that for me? 00:12:36.260 --> 00:12:36.380 Yeah. 00:12:36.920 --> 00:12:39.520 Yeah, so this is how Bitcoin nodes now actually work. 00:12:39.700 --> 00:12:40.060 That's right. 00:12:40.120 --> 00:12:43.480 They first listen, they don't store anything, but then if it sounds actually 00:12:43.480 --> 00:12:46.720 interesting, if they see the proof of work, they just ask again and they get all 00:12:46.720 --> 00:12:49.540 the blocks again. They're like, wow, that's cool. They get all the headers again, 00:12:49.560 --> 00:12:51.340 I guess, or do they now also get the blocks? 00:12:51.440 --> 00:12:54.540 Well, then once those headers have been downloaded the second time, things 00:12:54.540 --> 00:12:58.720 continue as always. You just start fetching blocks for the headers. Now there is, 00:12:58.800 --> 00:13:03.240 of course, a little gotcha there because, well, who says that the second time 00:13:03.240 --> 00:13:07.410 you're getting the same headers is the first time? You don't know that because 00:13:07.410 --> 00:13:13.190 you didn't store them. So what you do instead is you store one checksum, which is 00:13:13.190 --> 00:13:18.530 a one-bit checksum every 50,000 blocks or so. So every 50,000 headers, you store 00:13:18.530 --> 00:13:22.780 a zero or a one, depending on the contents of those headers. And you do that 00:13:22.780 --> 00:13:28.120 every 50,000 headers, that is very little information, but it turns out that it's 00:13:28.120 --> 00:13:31.180 actually quite difficult for anybody to fake that information. So it's… for… 00:13:31.180 --> 00:13:35.140 anybody to create fake headers that do match your checksum, even though it's a 00:13:35.140 --> 00:13:35.900 very small checksum. 00:13:36.100 --> 00:13:40.480 Right, yeah. A checksum is essentially you add up all kinds of numbers and you 00:13:40.480 --> 00:13:44.530 get a very short number. Which doesn't in itself prove anything, but I guess if 00:13:44.530 --> 00:13:46.630 you do it a bunch of times, then... 00:13:46.630 --> 00:13:48.670 If you added the same numbers, you're going to get the same checksum. 00:13:48.850 --> 00:13:49.290 Right, exactly. 00:13:49.410 --> 00:13:53.290 So if you have 50,000 headers, you add all those up together, then you get either 00:13:53.290 --> 00:13:56.790 a 1 or a 0. If you change any of the headers, well, you'll either get a 1 or a 0, 00:13:56.910 --> 00:14:01.010 but it might be a different one. Now that, of course, is a 50-50 chance. So 00:14:01.010 --> 00:14:06.800 that's pretty easy for a hacker to go after, but there are many blocks. So it 00:14:06.800 --> 00:14:10.180 turns out that for long enough... I might be wrong on the exact number. It might 00:14:10.180 --> 00:14:15.940 be less than 50,000. But if you have enough of those one-bit checks, basically, 00:14:16.160 --> 00:14:20.200 then it becomes quite hard for an attacker to create a fake chain that has enough 00:14:20.200 --> 00:14:22.920 proof of work, but that is different from the last one they sent you. 00:14:23.400 --> 00:14:25.360 Yep. Okay, that makes sense. 00:14:25.720 --> 00:14:25.920 Yep. 00:14:26.200 --> 00:14:31.930 So the... There's still a small part of the problem left, which is you do still 00:14:31.930 --> 00:14:33.650 need to download it the first time. 00:14:33.870 --> 00:14:34.130 Yes. 00:14:34.290 --> 00:14:36.990 But it solves another part of the problem, essentially. 00:14:37.150 --> 00:14:40.550 Yeah, so the downside is you're downloading headers twice, so that might be 00:14:40.550 --> 00:14:46.230 another 100 megabytes or so in the ideal case. However, compared to the size of 00:14:46.230 --> 00:14:50.650 the blockchain, that's not too bad. And compared to the worst case attack, it's 00:14:50.650 --> 00:14:51.470 definitely not bad. 00:14:53.030 --> 00:14:58.130 And of course, even if an attacker would want to try this for some reason, it's 00:14:58.130 --> 00:15:03.540 also costing the attacker resources because he has to upload all the data, the 00:15:03.540 --> 00:15:08.460 same data you have to download. It doesn't really do much, this attack, right? It 00:15:08.460 --> 00:15:10.520 can't allow you to steal coins or anything like that. 00:15:10.520 --> 00:15:13.740 Well, with this defense, no, because all they can do is waste your bandwidth. And 00:15:13.740 --> 00:15:16.820 there are many ways to waste your bandwidth, right? An attacker can just send you 00:15:16.820 --> 00:15:22.790 a gigabyte block and... or just complete gibberish in general. So that's not a 00:15:22.790 --> 00:15:23.230 new problem. 00:15:24.390 --> 00:15:28.170 Okay, so this was included in Bitcoin Core 24 and will be... 00:15:28.170 --> 00:15:31.490 Yeah, and the checkpoints are still there, but the idea would be to remove them 00:15:31.490 --> 00:15:32.450 eventually. 00:15:32.690 --> 00:15:35.990 Okay, so that would be removed in a future release. 00:15:36.130 --> 00:15:38.810 Yeah, and of course, you know, there has to be some additional discussion to make 00:15:38.810 --> 00:15:41.750 sure that that was really the last thing we needed, that the checkpoints are not 00:15:41.750 --> 00:15:44.090 also protecting against something else that we forgot about. 00:15:45.180 --> 00:15:50.970 Right. Okay. Well, that's the peer-to-peer part of Bitcoin 24. Then 00:15:50.970 --> 00:15:56.910 the next point is Mempool uses full RBF now or can use full RBF? 00:15:57.030 --> 00:15:58.130 Can use full RBF. 00:15:58.230 --> 00:15:58.350 Right. 00:15:58.550 --> 00:16:02.330 So it used to be that if you wanted, I think we've done an episode about replaced 00:16:02.330 --> 00:16:03.270 by fee RBF. 00:16:03.410 --> 00:16:03.510 Yes. 00:16:03.570 --> 00:16:05.510 So I think the listeners should listen to that. 00:16:05.730 --> 00:16:07.950 Well, you can summarize it in two sentences. 00:16:08.190 --> 00:16:12.690 Yeah. So basically the Bitcoin protocol itself, when you have one transaction and 00:16:12.690 --> 00:16:15.900 then you want to double spend it. There's nothing stopping you from doing that 00:16:15.900 --> 00:16:20.140 before it's in a block, right? Now, from an incentive point of view, miners are 00:16:20.140 --> 00:16:23.800 most likely to include the block with the highest fee, but they don't necessarily 00:16:23.800 --> 00:16:29.310 have to. And so there was a proposal by Peter Todd many, many years ago 00:16:29.310 --> 00:16:35.230 to say, well, normally the nodes, well, let's go one step back. So what miners 00:16:35.230 --> 00:16:38.730 do is ultimately up to miners. You have no control over that. And Bitcoin Core 00:16:38.730 --> 00:16:41.470 can change things in the software, but miners will do whatever they do because 00:16:41.470 --> 00:16:47.350 what the mempool does is not consensus. However, the nodes will relay 00:16:47.350 --> 00:16:51.370 transactions. And so you can change the nodes to say, well, I'm going to... 00:16:51.240 --> 00:16:54.440 broadcast some transactions and not going to rebroadcast other transactions. And 00:16:54.440 --> 00:17:00.300 so this new rule, opt-in replaced by fee, opt-in RBF, basically said that 00:17:00.300 --> 00:17:04.100 normally we only broadcast the first version of the transaction we see, 00:17:04.320 --> 00:17:07.260 regardless of the second one. It doesn't matter if the second one pays more fees. 00:17:08.060 --> 00:17:11.820 But if you put a flag in the transaction that says, I want to opt-in to replace 00:17:11.820 --> 00:17:17.140 by fee, then nodes will relay transactions that pay a higher fee 00:17:17.140 --> 00:17:22.340 only and a bunch of other constraints. And so this gives the recipient some 00:17:22.340 --> 00:17:27.120 assurance, not much, but some assurance that if this flag is present, this 00:17:27.120 --> 00:17:29.980 transaction could be replaced anytime. You really have to wait for it to confirm. 00:17:30.340 --> 00:17:34.220 If it doesn't have this flag, it might still disappear. It's just a little bit 00:17:34.220 --> 00:17:34.740 less likely. 00:17:35.600 --> 00:17:39.780 Yeah, I want to clarify one thing because you mentioned double spending in this 00:17:39.780 --> 00:17:43.540 context. And you are, of course, right that this can be used to double spend 00:17:43.540 --> 00:17:48.780 until it's included in a block, as you said. But the main purpose or the main 00:17:48.780 --> 00:17:53.320 idea for using a flag, for example, is to increase the fee on your own 00:17:53.320 --> 00:17:54.080 transaction, right? 00:17:54.240 --> 00:17:57.360 That's definitely, I don't know how long that idea has been around because the 00:17:57.360 --> 00:18:02.240 idea of being stuck in a mempool, that concept didn't even exist until 2015 or 00:18:02.240 --> 00:18:03.720 2016. That was never a problem. 00:18:04.390 --> 00:18:08.170 Yeah, but the flag was introduced around that time and definitely in the context 00:18:08.170 --> 00:18:09.530 of that. That was the debate. 00:18:09.790 --> 00:18:09.950 Okay. 00:18:10.250 --> 00:18:11.170 Yeah, I'm sure about that. 00:18:12.430 --> 00:18:18.350 So to summarize that, at least the idea for the flag was 00:18:18.350 --> 00:18:21.790 you send a transaction, but the mempool was full and therefore your transaction 00:18:21.790 --> 00:18:27.310 is not confirming. Now with the RBF flag, you can basically resend the same 00:18:27.310 --> 00:18:31.570 transaction with a higher fee and therefore... Because the flag is included, 00:18:31.730 --> 00:18:36.830 nodes will actually forward it to miners and it can be included in a block. Now, 00:18:36.830 --> 00:18:42.760 you don't actually need to include the flag anymore. If this setting 00:18:42.760 --> 00:18:43.480 is turned on? 00:18:44.000 --> 00:18:48.020 Yeah, I think that if you turn the setting on, then the flag does no longer have 00:18:48.020 --> 00:18:52.680 to be in there. It'll relay it anyway. I'm guessing there are other rules, 00:18:52.720 --> 00:18:56.090 though, because I assume the fee has to go up. But I'm not sure about that. 00:18:56.090 --> 00:19:01.490 So in my case if so far I was running a Bitcoin Core node let's say what was the 00:19:01.490 --> 00:19:06.510 previous one 23 of course so far I was running Bitcoin Core 23 and then my node 00:19:06.510 --> 00:19:12.250 would not forward a transaction even if it had a higher fee and it 00:19:12.250 --> 00:19:16.150 conflicted with the previous transaction it would not do that but now with 00:19:16.150 --> 00:19:20.650 Bitcoin 24 I can switch the setting and now it will actually forward that 00:19:20.650 --> 00:19:21.110 transaction? 00:19:22.240 --> 00:19:27.100 Yeah, I think that's it. And it basically means that if you're relying on this 00:19:27.100 --> 00:19:31.480 opt-in RBF system to prevent double spends, basically to prevent double spends, 00:19:31.640 --> 00:19:35.840 you should now rely on that less so because there's going to be more nodes that 00:19:35.840 --> 00:19:37.020 will relay this thing regardless. 00:19:37.400 --> 00:19:41.430 Yeah, well, I mean, it was almost... Well, I don't know about almost certainly, 00:19:41.590 --> 00:19:44.870 but there's definitely a much bigger chance that a conflicting transaction will 00:19:44.870 --> 00:19:48.330 make it to a miner now, right? Because I think there only needs to be a 00:19:48.330 --> 00:19:52.270 relatively small amount of nodes on the network that actually do it for a 00:19:52.270 --> 00:19:54.570 transaction to just find its way over the entire network. 00:19:54.690 --> 00:19:57.790 But there was already ways to do it, right? There was a patch by Peter Todd, 00:19:57.870 --> 00:20:01.870 which was pretty small, and you could use that to modify your nodes. So there's 00:20:01.870 --> 00:20:04.430 already some nodes doing it. Now there's more, presumably. 00:20:04.790 --> 00:20:05.130 Right. 00:20:08.550 --> 00:20:12.930 So does this mean that some merchants are going to be unhappy? 00:20:13.310 --> 00:20:15.990 Well, they might be for that reason. 00:20:15.990 --> 00:20:18.290 There are still some merchants that rely on zero-conf. 00:20:18.390 --> 00:20:21.470 Yeah, there are definitely merchants that do that. But the flip side is that 00:20:21.470 --> 00:20:26.230 there's also merchants that use Lightning. And Lightning is generally bothered a 00:20:26.230 --> 00:20:30.970 lot by the existing RBF rules because they make it much more complicated to deal 00:20:30.970 --> 00:20:35.310 with penalty transactions. So on the long run, they may get a better Lightning 00:20:35.310 --> 00:20:36.930 experience out of this. 00:20:37.170 --> 00:20:42.400 Right. Yeah I mean my personal opinion is that this should just be the general 00:20:42.400 --> 00:20:42.820 rule. 00:20:45.410 --> 00:20:50.050 Transactions should always be broadcast and forwarded, especially if they have a higher fee. 00:20:50.670 --> 00:20:53.970 I mean, maybe. We've already had this discussion during that episode, I guess. 00:20:54.070 --> 00:20:57.990 But I would also say that if you just turn on the RBF flag by default, it 00:20:57.990 --> 00:21:03.170 shouldn't bother you either. But I think the bigger problem is that this RBF flag 00:21:03.170 --> 00:21:06.710 has very specific rules. It's not just that you set the flag. You also have to do 00:21:06.710 --> 00:21:11.550 a few other things. And those other things cause complications. So that could be 00:21:11.550 --> 00:21:14.770 a reason to say, you know what, let's forget about this opt-in RBF completely and 00:21:14.770 --> 00:21:18.630 relay everything that is reasonable. But there are trade-offs. One is just 00:21:18.630 --> 00:21:24.270 bandwidth. Because if my node relays everything that you send to it, 00:21:24.390 --> 00:21:28.650 I could send you one transaction and then increase it by one satoshi per byte or 00:21:28.650 --> 00:21:31.790 increase it by, don't even increase the fee, but just change the destinations a 00:21:31.790 --> 00:21:34.270 bit. And I could send you millions and millions of variations of the same 00:21:34.270 --> 00:21:38.570 transaction, basically wasting everybody's bandwidth. So it's not entirely 00:21:38.570 --> 00:21:39.450 without trade-offs. 00:21:40.970 --> 00:21:46.440 Fair. All right, let's move on to the third point. So we mentioned change on the 00:21:46.440 --> 00:21:49.620 peer-to-peer network, the block header thing, and we just mentioned RBF. And then 00:21:49.620 --> 00:21:54.160 the third point is this is related to descriptor wallets and migration to 00:21:54.160 --> 00:21:55.160 descriptor wallets. 00:21:55.400 --> 00:21:59.560 Yeah, I'm not sure how much we covered descriptor wallets so far, but the gist of 00:21:59.560 --> 00:22:04.900 it is that the Bitcoin Core wallet is quite old. It used to be just a bag of 00:22:04.900 --> 00:22:09.070 keys. And then, you know, given a private key, the wallet would have to pay 00:22:09.070 --> 00:22:12.050 attention to certain scripts. I think in one of the first episodes we explained 00:22:12.050 --> 00:22:15.690 what scripts are. But the simplest scripts is just that anybody with the public 00:22:15.690 --> 00:22:20.650 key can spend this coin. The second simplest script is anybody with the hash of 00:22:20.650 --> 00:22:26.630 the public key can spend the coin. Or anybody with the public key 00:22:26.630 --> 00:22:28.390 for which the hash is blah, blah, blah. 00:22:28.750 --> 00:22:29.110 Yeah. 00:22:29.970 --> 00:22:34.330 But then later on came SegWit, and that created another two variations of how you 00:22:34.330 --> 00:22:35.110 could spend the coins. 00:22:35.270 --> 00:22:35.550 Right. 00:22:35.550 --> 00:22:39.890 Because you had the address of bc1, and you had the address that looked like a 00:22:39.890 --> 00:22:42.440 P2SH address. With SegWit wrapped in it. 00:22:42.840 --> 00:22:42.940 Right. 00:22:43.060 --> 00:22:45.180 So the wallet just became a giant mess. 00:22:45.360 --> 00:22:47.860 Also, you have multisig rates and stuff like that. 00:22:47.960 --> 00:22:52.260 Well, yeah, that makes it even more complicated. But basically, the Bitcoin Core 00:22:52.260 --> 00:22:56.260 wallet became a bit unwieldy. And so one of the improvements that was introduced 00:22:56.260 --> 00:23:01.200 was to create a new way to store data and basically saying, well, here's keys, 00:23:01.400 --> 00:23:06.400 but more importantly, here's exactly what scripts you want to watch for. So you 00:23:06.400 --> 00:23:10.460 can specifically say, I only want to check for Taproot transactions for this 00:23:10.460 --> 00:23:15.410 private key and not also for legacy transactions for this private key. Now your 00:23:15.410 --> 00:23:16.210 wallet handles all this. 00:23:16.510 --> 00:23:20.130 What's the practical benefits of that? Just less resources? 00:23:20.250 --> 00:23:23.630 No, for the end user, this doesn't matter. It just means that their wallet 00:23:23.630 --> 00:23:27.310 software is better maintained because it's less of a headache for the wallet 00:23:27.310 --> 00:23:31.010 developers to deal with this. So it basically involves a giant rewrite, mostly 00:23:31.010 --> 00:23:35.740 done by Andrew Chow. And one of the challenges there is we have this old wallet 00:23:35.740 --> 00:23:40.000 and we want to move people over to the new wallet. And so the first step for that 00:23:40.000 --> 00:23:45.320 is this new RPC call called migratewallet, which does what it says it does. 00:23:46.060 --> 00:23:47.500 It will migrate your wallet? 00:23:47.740 --> 00:23:52.420 Yeah. And for the simplest cases, you know, if you created a wallet in the last 00:23:52.420 --> 00:23:56.480 couple of years and you didn't do anything super fancy, very complicated multisig 00:23:56.480 --> 00:24:00.000 setups, whatever, this will work. If you did do something complicated, then 00:24:00.000 --> 00:24:03.720 please test it. It'll make a backup, but maybe make your own backup too. 00:24:04.060 --> 00:24:04.400