WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:14.450 --> 00:00:17.170 Live from the internet, this is Bitcoin 00:00:17.360 --> 00:00:18.980 Explained. 00:00:19.600 --> 00:00:20.540 How are you, Sjors? 00:00:21.200 --> 00:00:22.660 Hello, how are you? 00:00:23.100 --> 00:00:24.240 It's been a while. 00:00:24.580 --> 00:00:25.620 It's been a few days. 00:00:26.080 --> 00:00:30.720 Yeah, we haven't made an episode because we always committed to only making 00:00:30.720 --> 00:00:35.240 episodes live in person. There were some exceptions, but I think neither of us 00:00:35.240 --> 00:00:39.630 really liked that, so we kind of made it a rule. But I haven't been in the 00:00:39.630 --> 00:00:44.570 Netherlands for a while now, never mind in Utrecht, so we couldn't do it. We 00:00:44.570 --> 00:00:46.670 decided to pick up where we left anyways. 00:00:47.750 --> 00:00:51.610 Yeah, especially because this is a topic that really nobody talks about, and I 00:00:51.610 --> 00:00:52.130 think we should. 00:00:53.130 --> 00:00:57.970 Yeah, there's apparently a very obscure new software release called Bitcoin Core 00:00:57.970 --> 00:01:02.990 30, and we thought maybe it's time that someone brings it under the attention of 00:01:02.990 --> 00:01:08.110 the people out there. On that point, I do want to start with that a little bit 00:01:08.110 --> 00:01:12.270 because I think this has been the most... 00:01:12.000 --> 00:01:13.750 Do we want to thank our sponsor? 00:01:15.490 --> 00:01:20.410 Yes. Thank you, CoinKite. Thanks for being our sponsor. Thanks for making 00:01:20.410 --> 00:01:25.350 the brilliant COLDCARD and all the other magical devices 00:01:25.350 --> 00:01:29.900 you put out there. What's the... Sjors, help remind me. What's the little USB 00:01:29.900 --> 00:01:30.480 thingy called? 00:01:31.420 --> 00:01:33.860 I think it was the coin... The COLDPOWER. 00:01:34.440 --> 00:01:35.380 No. But it's like a... 00:01:36.200 --> 00:01:37.660 Oh, you mean the OPENDIME. 00:01:37.860 --> 00:01:38.860 The OPENDIME. 00:01:38.960 --> 00:01:39.660 The legend. 00:01:40.140 --> 00:01:45.040 Yeah. Yes. Legendary. Legendary CoinKite. Thanks for sponsoring us. 00:01:46.320 --> 00:01:47.120 Oh, my God. 00:01:47.440 --> 00:01:51.160 I think the OPENDIME still doesn't support Taproot because I opened a pull 00:01:51.160 --> 00:01:55.320 request once to make it use Taproot and they closed it because it wasn't 00:01:55.320 --> 00:01:56.860 cockroach enough. 00:01:58.100 --> 00:01:58.660 Anywho. 00:01:59.400 --> 00:01:59.880 Anyways. 00:02:00.180 --> 00:02:01.900 Let's talk about this obscure piece of software. 00:02:02.080 --> 00:02:07.360 Oh, yeah. So I wanted to ask you, you know, okay, we're mostly going to be 00:02:07.360 --> 00:02:11.700 making a drama-free episode here. You know, we're going to discuss what's 00:02:11.700 --> 00:02:13.140 actually new in Bitcoin Core 30. 00:02:14.520 --> 00:02:20.160 Like I said, it does seem like this has been probably the most controversial 00:02:20.160 --> 00:02:22.980 Bitcoin Core release ever. 00:02:26.220 --> 00:02:32.160 Social media community has been sort of ablaze over all of this. I 00:02:32.160 --> 00:02:37.060 don't think I've seen it this bad since the block size wars and in some ways even 00:02:37.060 --> 00:02:42.500 worse than the block size wars. And I'm just sort of wondering, you as a Bitcoin 00:02:42.500 --> 00:02:47.840 Core developer, I know you're not on Twitter, you're not on X. How much are you 00:02:47.840 --> 00:02:52.840 seeing of this or how much does it affect you and maybe others? Can you give some 00:02:52.840 --> 00:02:54.500 sort of estimation of that? 00:02:55.120 --> 00:02:59.400 Yeah, I guess compared to the block size wars, because the community was smaller 00:02:59.400 --> 00:03:02.560 too, this is probably actually smaller in relative terms. 00:03:03.880 --> 00:03:09.360 But it's just more money to be made and more attention to be had on social media. 00:03:09.740 --> 00:03:13.020 Maybe social media is just worse than it was 10 years ago. 00:03:14.720 --> 00:03:20.460 Yeah, like I said, I try to just ignore things as much as possible other than the 00:03:20.460 --> 00:03:26.300 actual facts. because just arguing with people on Twitter or even Nostr is just a 00:03:26.300 --> 00:03:30.880 huge energy drain. We did record a whole episode on probably the most 00:03:30.880 --> 00:03:34.200 controversial part of it. That's our previous episode, The Return of the 00:03:34.200 --> 00:03:38.580 OP_RETURN, so people can listen to that. And I don't think anything has changed, 00:03:38.600 --> 00:03:43.740 although I think we'll address a couple of very minor things here. 00:03:44.720 --> 00:03:45.780 in the release notes 00:03:45.780 --> 00:03:50.320 yeah yeah but yeah i mean that's a good uh sort of non-spoiler warning maybe 00:03:50.320 --> 00:03:54.660 we're not gonna spend half an hour discussing this change because we made a whole 00:03:54.660 --> 00:04:00.480 episode about it anyone who wants to know how Sjors thinks about 00:04:00.480 --> 00:04:05.220 that or me i can go to the previous episodes uh previous episodes and that's 00:04:05.220 --> 00:04:07.920 where we really discussed the you know the OP_RETURN limit change 00:04:07.920 --> 00:04:13.360 well now i would say uh if you look at um say the github repo and you know 99 00:04:13.970 --> 00:04:17.130 percent of the work on Bitcoin Core is completely unrelated to these 00:04:17.130 --> 00:04:23.130 controversial changes. And that work just continues as before. It's interesting 00:04:23.130 --> 00:04:28.970 how, you know, there's like 350 open pull requests on the GitHub repo and 00:04:28.970 --> 00:04:33.930 they're almost all like silos. So one pull request can be super crowded and noisy 00:04:33.930 --> 00:04:37.010 and the other one is completely deserted and nobody's even looking at it. 00:04:37.660 --> 00:04:38.140 Yeah. 00:04:38.840 --> 00:04:42.860 I think I've made the analogy before that the Bitcoin Core project sometimes 00:04:42.860 --> 00:04:48.200 feels like you have a very large brutalist office building and everybody has a 00:04:48.200 --> 00:04:52.540 little cubicle. And if you're in that cubicle, your pull request is like a 00:04:52.540 --> 00:04:56.880 cubicle. You might be in multiple cubicles, I guess. But if nobody comes by, then 00:04:56.880 --> 00:04:58.060 nobody can hear you. 00:04:58.440 --> 00:05:03.710 Yeah. Okay, well, regardless, let's actually kick off with that specific topic 00:05:03.710 --> 00:05:09.230 just to get it out of the way. So the OP_RETURN policy limit has been 00:05:09.230 --> 00:05:11.630 lifted basically entirely, right? 00:05:14.080 --> 00:05:19.280 Again, I think we've said enough about that. Anyone who wants to know the details 00:05:19.280 --> 00:05:23.880 about that can go to the previous episode. However, there is also another related 00:05:23.880 --> 00:05:29.580 change that's close to it, but that we did not discuss in the previous episode. 00:05:31.060 --> 00:05:34.340 I think there's also a policy... 00:05:35.570 --> 00:05:40.790 policy rule is that it's now also possible besides bigger OP_RETURNs to include 00:05:40.790 --> 00:05:45.370 multiple OP_RETURNs in one transaction, right? We did not cover that last time. 00:05:45.750 --> 00:05:50.850 I'm not sure if we did, but we can just repeat it. Yes. So you can either make 00:05:50.850 --> 00:05:55.210 one OP_RETURN that is the maximum size of a transaction or less, or you can make 00:05:55.210 --> 00:06:00.270 multiple ones, which, you know, can ultimately add up to the same size. 00:06:00.820 --> 00:06:02.380 Yeah, that's important to note. 00:06:02.660 --> 00:06:05.000 I would say that's mostly a simplification. 00:06:06.770 --> 00:06:11.950 Well, it's important to note because, you know, in this entire shitstorm, it has 00:06:11.950 --> 00:06:17.810 been brought up as well as like another supposedly bad thing 00:06:17.810 --> 00:06:23.210 that Bitcoin Core developers have done. But as you point out, even if there are 00:06:23.210 --> 00:06:28.140 multiple OP_RETURNs in a transaction, the 00:06:28.140 --> 00:06:34.040 total size of these OP_RETURN, are still bound to whatever the limit is and 00:06:34.040 --> 00:06:37.980 this limit even in Bitcoin Core is still configurable right uh 00:06:38.680 --> 00:06:42.200 yeah so we kind of went back and forth on that the initial idea was to completely 00:06:42.200 --> 00:06:45.620 drop it because it's essentially a placebo but you know there was a lot of drama 00:06:45.620 --> 00:06:50.160 so eventually i think now the default has been changed like there's no limit but 00:06:50.160 --> 00:06:54.420 if you do set a limit the only difference between now and before is that the 00:06:54.420 --> 00:06:59.740 limit applies to the total for transactions so Let's say you set the limit to 83 00:06:59.740 --> 00:07:05.300 bytes. That was, I think, the previous default. Then somebody could make, I 00:07:05.300 --> 00:07:10.460 guess, you know, 20 OP_RETURNs of two bytes each if they somehow wanted to. Now, 00:07:10.520 --> 00:07:14.300 that'd be pretty expensive for them because every output has an overhead. 00:07:15.170 --> 00:07:19.010 Yeah, I'm pointing it out because there was a point of critique, as I mentioned, 00:07:19.270 --> 00:07:22.790 that, okay, you can change the default setting now. You can change it back to 00:07:22.790 --> 00:07:27.710 where it was. But the critique was, but now you can still include multiple 00:07:27.710 --> 00:07:32.770 OP_RETURNs in a transaction. However, the point is that if you do change it back 00:07:32.770 --> 00:07:37.470 to, let's say, 83 bytes, then if you then put multiple OP_RETURNs in a 00:07:37.470 --> 00:07:43.150 transaction, then their combined size can still only be 83 bytes. So even if you 00:07:43.150 --> 00:07:47.510 change it... If you do change the defaults for whatever reason you may think you 00:07:47.510 --> 00:07:52.830 want to do that, then that is still the actual limit for OP_RETURNs. 00:07:53.110 --> 00:07:57.210 Yeah, you can split it up in two different OP_RETURNs, but it's still 83 bytes in 00:07:57.210 --> 00:07:58.330 that case, right? 00:07:59.150 --> 00:07:59.430 Mm-hmm. 00:07:59.870 --> 00:08:04.770 Yeah, okay. So then why you said the change was made, and I'm talking again 00:08:04.770 --> 00:08:09.590 specifically about the fact that you can include multiple OP_RETURNs, that was 00:08:09.590 --> 00:08:10.790 made as a simplification? 00:08:12.220 --> 00:08:16.540 Yeah, I mean, it depends on how you look at it, I guess. But the idea was there 00:08:16.540 --> 00:08:19.940 can only be one, so that restriction is dropped. Now it doesn't matter how many 00:08:19.940 --> 00:08:24.240 outputs are OP_RETURNs. So the rules are simplified. Whether that actually is 00:08:24.240 --> 00:08:27.920 simpler in the code, that's debatable, right? Now you have to check the total 00:08:27.920 --> 00:08:31.780 against multiple outputs. As long as the option is there at all, there's some 00:08:31.780 --> 00:08:34.820 complexity. As long as you remove the option, it becomes simpler because you're 00:08:34.820 --> 00:08:39.180 just not counting it at all. But now, you know, it has to count, like look at the 00:08:39.180 --> 00:08:41.980 first output, look at the second output, look at the third output, and then 00:08:41.980 --> 00:08:43.740 complain when something goes over it. 00:08:45.320 --> 00:08:49.640 And because, you know, because we're talking about a policy rule, you know, just 00:08:49.640 --> 00:08:53.900 to repeat this point, it does not apply to the consensus rules. If your node 00:08:53.900 --> 00:08:57.340 receives a block with a transaction in it that has... 00:08:58.800 --> 00:09:03.280 you know, bigger OP_RETURNs than whatever setting you're switching it to, then 00:09:03.280 --> 00:09:04.280 you'll still accept that. 00:09:04.900 --> 00:09:08.880 Yeah, in fact, you know, a block could contain a four megabyte OP_RETURN in a 00:09:08.880 --> 00:09:12.800 single transaction, right? Which would not be even possible with the new Bitcoin 00:09:12.800 --> 00:09:13.820 Core over the mempool. 00:09:14.420 --> 00:09:14.560 Yeah. 00:09:15.420 --> 00:09:18.400 Each transaction is limited to 100 kilobyte in general. 00:09:18.830 --> 00:09:23.830 Yeah, so what is technically new in this specific instance is that there can now 00:09:23.830 --> 00:09:29.130 be multiple OP_RETURNs in a transaction on whatever size you want to put that 00:09:29.130 --> 00:09:33.730 setting. And then if it's within that size, you will accept it in your mempool 00:09:33.730 --> 00:09:35.290 and relay it to other nodes, correct? 00:09:35.950 --> 00:09:40.470 Yes. And so just a little bit more background on why, you know, such as, I mean, 00:09:40.570 --> 00:09:44.510 first of all, if the setting was entirely removed, which was the initial idea, 00:09:44.710 --> 00:09:46.070 it's actually a simplification. 00:09:47.370 --> 00:09:50.510 But because the setting is still there, we still need to look at the total. So 00:09:50.510 --> 00:09:53.990 you could argue it's not really a simplification, but it is in the long run. But 00:09:53.990 --> 00:09:57.890 another reason to do this is because if somebody has a need to have multiple 00:09:57.890 --> 00:10:02.750 OP_RETURNs, and I don't know if anybody does at the moment, but if they do, and 00:10:02.750 --> 00:10:08.310 we still have this limit of one OP_RETURN output per 00:10:08.310 --> 00:10:12.290 transaction, then there is another incentive for people to go outside the 00:10:12.290 --> 00:10:16.770 mempool. And you use accelerators, which creates the centralization pressure that 00:10:16.770 --> 00:10:18.270 we tried to solve in the first place. 00:10:18.710 --> 00:10:24.290 Yeah. And on that point, what I also find interesting 00:10:24.290 --> 00:10:29.650 to sort of highlight here is that your reasoning... So you 00:10:29.650 --> 00:10:35.340 said... We don't know if there's a use case for it. Maybe there isn't. That in 00:10:35.340 --> 00:10:39.680 itself has drawn a lot of ire. There seem to be a lot of people that feel that 00:10:39.680 --> 00:10:43.560 unless you can prove that there is a use case for it, you shouldn't make any 00:10:43.560 --> 00:10:46.660 changes. While you, and I agree with you, 00:10:47.870 --> 00:10:53.750 see it more as, well, if there's no harm, then what's the problem? If there's no 00:10:53.750 --> 00:10:56.710 harm and you simplify the code, then that seems like an improvement. 00:10:57.990 --> 00:11:02.450 Yeah, I guess in this case, where the confusion comes from is, or potentially 00:11:02.450 --> 00:11:07.200 comes from, is that initially the idea was to drop the setting entirely. And 00:11:07.200 --> 00:11:12.700 because we haven't dropped it entirely now, the simplicity argument isn't as strong. 00:11:14.160 --> 00:11:17.740 But yeah, the problem with these alternative use cases is if you wait until 00:11:17.740 --> 00:11:22.360 they're actually fully deployed... and they go around the mempool because, you 00:11:22.360 --> 00:11:27.000 know, they're already deployed. Now you lift the limit and, well, they're already 00:11:27.000 --> 00:11:30.760 going around the mempool. So, you know, why would they change anything? So you 00:11:30.760 --> 00:11:33.900 might be too late if you keep chasing these things and Bitcoin Core only releases 00:11:33.900 --> 00:11:37.820 once every six months. And we'll have another topic on the list where something 00:11:37.820 --> 00:11:42.600 similar happens where it was a response to actual behavior. So we were a little 00:11:42.600 --> 00:11:44.620 bit late at this time, I guess. 00:11:45.000 --> 00:11:48.860 Yeah, yeah. So if you're being reactive on these things, you're actually too 00:11:48.860 --> 00:11:53.420 late. And then if there's no harm in doing it, then it's better to just do it now 00:11:53.420 --> 00:11:55.080 in case someone might need it. 00:11:55.540 --> 00:11:59.600 Especially because the total amount doesn't change, right? Like you said, you can 00:11:59.600 --> 00:12:00.680 spread it over multiple outputs. 00:12:01.020 --> 00:12:01.360 Yeah. 00:12:02.800 --> 00:12:08.160 Yeah, okay, let's move on from that point. Anyone who was listening specifically 00:12:08.160 --> 00:12:12.200 to hear more about the OP_RETURN drama can now switch off because we're going to 00:12:12.200 --> 00:12:17.840 talk about other interesting, notable improvements in Bitcoin Core 30, right? Or 00:12:17.840 --> 00:12:19.540 was there anything else you wanted to say about this? 00:12:20.300 --> 00:12:23.820 Yes, but I was just changing the sequence of 00:12:24.040 --> 00:12:27.800 items on our to-do list. 00:12:32.890 --> 00:12:35.330 All right, let's talk about the minimum relay fee then. 00:12:37.860 --> 00:12:42.200 Because that's sort of in the same area of changes. And then we'll move on to 00:12:42.200 --> 00:12:43.360 completely different changes. 00:12:44.280 --> 00:12:48.720 Okay. It was very important to adjust that in the Google Doc that no one else 00:12:48.720 --> 00:12:53.160 will see besides you and me. Good thing that you did that. Exactly. 00:12:54.300 --> 00:13:00.020 Okay. So yeah, so this is another policy change, 00:13:00.260 --> 00:13:05.860 which, okay, so that's the minimum fee that is included in the 00:13:05.860 --> 00:13:11.720 transaction, can now be lower before Bitcoin Core node will accept it in the 00:13:11.720 --> 00:13:13.540 mempool and relay it to other nodes, right? 00:13:13.820 --> 00:13:18.100 Yeah, so it used to be one satoshi per vbyte, now it's a 0.1 satoshi per vbyte. 00:13:18.490 --> 00:13:24.190 And this is a case of people start doing things and Bitcoin Core has to follow. 00:13:24.370 --> 00:13:26.390 Otherwise, everybody will go around the mempool. 00:13:28.280 --> 00:13:32.580 So what started happening is because the fee market is such an amazing success. 00:13:34.320 --> 00:13:40.230 Yeah, people wanted to pay less fees. And well, like I said, I'm not on social 00:13:40.230 --> 00:13:44.050 media myself at the moment. But what my understanding is that there was sort of a 00:13:44.050 --> 00:13:49.180 Twitter movement to... for people to individually configure their relay fee to go 00:13:49.180 --> 00:13:50.940 lower by factor 10. 00:13:51.200 --> 00:13:52.220 Yeah, and that was... 00:13:52.220 --> 00:13:54.060 Somebody just followed that example. 00:13:54.920 --> 00:13:59.940 And so that was... Sure, that was always possible with Bitcoin Core. Any 00:13:59.940 --> 00:14:05.580 individual user could already lower the min relay fee. 00:14:05.900 --> 00:14:09.750 Yeah, it's a matter of changing a setting. Now, keep in mind, everything is 00:14:09.750 --> 00:14:13.230 possible with Bitcoin Core if you recompile it yourself. But in this case, it's 00:14:13.230 --> 00:14:17.890 just a matter of changing a setting. So you can already lower it to one 00:14:17.890 --> 00:14:22.770 thousandth of a satoshi per vbyte. Not lower, because the amounts internally are 00:14:22.770 --> 00:14:26.710 processed at that resolution. So you'd have to do some more changes if you want 00:14:26.710 --> 00:14:27.630 to go even lower than that. 00:14:29.090 --> 00:14:34.540 But I guess, yeah, people settled on about 10x lower. And some miners followed, 00:14:34.600 --> 00:14:37.980 and that means these things get mined. But that means if you don't change your 00:14:37.980 --> 00:14:41.360 default setting, now you're kind of surprised about what gets into blocks. 00:14:42.840 --> 00:14:47.560 And that surprise hurts compact block relay, among other things. So 00:14:47.560 --> 00:14:52.580 we talked about compact block relay in our previous episode. But generally the 00:14:52.580 --> 00:14:57.300 idea is that if you're sending a block to the next person down the line, to one 00:14:57.300 --> 00:15:01.410 of your peers, If you know what's in their mempool, you really only need to send 00:15:01.410 --> 00:15:05.270 the header of the block and a summary of the transactions, like a list of the 00:15:05.270 --> 00:15:10.810 transaction IDs, rather than the full block with all its contents. But if you 00:15:10.810 --> 00:15:13.310 don't know what's in somebody else's mempool because they changed some setting, 00:15:13.670 --> 00:15:17.870 now you have to send the whole block over. And so this delays propagation network-wide. 00:15:18.510 --> 00:15:23.190 Yeah, it's better for the health of the network if blocks find their way across 00:15:23.190 --> 00:15:29.010 the entire network as fast as possible. And that requires... that mempools 00:15:29.010 --> 00:15:34.530 closely reflect the actual blocks that are being mined. So if for whatever 00:15:34.530 --> 00:15:40.350 reason, the blocks start to look different, in this case, because very 00:15:40.350 --> 00:15:45.930 low fee transactions start to make their way to miners, then it's actually better 00:15:45.930 --> 00:15:51.810 for the health of the network that everyone adapts the same behavior. So 00:15:51.810 --> 00:15:56.400 in this case, Bitcoin... in this case, and also very relevant to the OP_RETURN 00:15:56.400 --> 00:16:01.800 issue, but in this case as well, Bitcoin Core has decided to 00:16:01.800 --> 00:16:07.540 allow lower fee transactions in the mempool and relay it to other 00:16:07.540 --> 00:16:11.680 nodes in order to better reflect the mempool with blocks that are being found. 00:16:11.900 --> 00:16:12.460 Good summary. 00:16:13.010 --> 00:16:18.250 Yes, and so this has been a general theme now over a few different topics. We've 00:16:18.250 --> 00:16:22.430 seen with RBF, full RBF, the changes. We've seen it with OP_RETURN. Now we're 00:16:22.430 --> 00:16:27.190 seeing it with the fee rate. And the response has been slightly different in 00:16:27.190 --> 00:16:32.370 different cases. So in the case of full RBF, you had somebody basically 00:16:32.370 --> 00:16:37.460 promoting that concept, releasing an alternative client, and then Bitcoin Core 00:16:37.460 --> 00:16:43.350 did not follow. until at some point, you know, all the miners or at least a large 00:16:43.350 --> 00:16:47.690 chunk of the miners were doing this and compact block relay was broken. And so 00:16:47.690 --> 00:16:51.050 then Bitcoin Core said, okay, let's turn RBF on. So arguably that was too late. 00:16:52.700 --> 00:16:57.340 But because we already had broken compact block relay and, you know, the longer 00:16:57.340 --> 00:17:02.620 you let that sort of centralization risk exist, you know, maybe at some point the 00:17:02.620 --> 00:17:07.350 damage is irreversible. Probably not in this case. Okay, so then we had the 00:17:07.350 --> 00:17:13.310 OP_RETURN stuff, where Bitcoin Core developers saw that a use case was 00:17:13.310 --> 00:17:19.310 imminent and tried to preempt it. That caused an enormous amount of drama. 00:17:20.070 --> 00:17:26.070 And now it's kind of in between, like this spontaneous change in policy by 00:17:26.070 --> 00:17:29.370 users, and Bitcoin Core follows it just a month or two later. 00:17:30.720 --> 00:17:35.280 Yeah, I don't think there's really consensus on how to best deal with this. Like 00:17:35.280 --> 00:17:39.540 these three options, you can either be too early or too late or right on time. 00:17:40.060 --> 00:17:45.860 And at some point, there might be a deviation from... from in 00:17:45.860 --> 00:17:51.500 policy that is simply not acceptable, as in it would just be unsafe, cause a DoS 00:17:51.500 --> 00:17:55.740 problem. And at that point, there's nothing Bitcoin Core can do other than 00:17:55.740 --> 00:18:00.320 propose a consensus change or just accept that nodes are slow or vulnerable or 00:18:00.320 --> 00:18:04.280 something bad like that. So it's not a healthy development, I think, but people 00:18:04.280 --> 00:18:07.060 do what they do, right? It's an open source, open system. 00:18:07.910 --> 00:18:12.810 Yeah, and I think that's an important point to emphasize here, because this says 00:18:12.810 --> 00:18:18.450 a lot about how the Bitcoin Core project sort of operates, is 00:18:18.450 --> 00:18:23.960 that... you know you guys you know you are one of the Bitcoin Core developers you 00:18:23.960 --> 00:18:29.300 don't see yourselves as authorities that decide how other people can or even 00:18:29.300 --> 00:18:33.380 should use the network it's not in your control how people what kind of 00:18:33.380 --> 00:18:39.200 transactions people send or what kind of transactions miners mine Bitcoin Core 00:18:39.200 --> 00:18:45.190 can only you know adjust to that so and then 00:18:45.190 --> 00:18:49.130 like you said there are like a couple of ways to do that which is either sort of 00:18:49.130 --> 00:18:53.510 you know do it in advance when you see it coming or only do it when it's kind of 00:18:53.510 --> 00:18:56.670 too late and that's sort of the difficult aspect here to balance 00:18:56.670 --> 00:19:01.530 or worse like you can't do it at all Because there might be some trade-off that's 00:19:01.530 --> 00:19:02.730 really unacceptable. 00:19:03.410 --> 00:19:08.290 Yeah. So this is a good example of that as well. Users were already starting to 00:19:08.290 --> 00:19:13.630 relay very low fee transactions. Miners were already starting to mine that. So 00:19:13.630 --> 00:19:18.290 then Bitcoin Core in this release said, okay, we're going to lower the fee 00:19:18.290 --> 00:19:20.470 minimum in order to better. 00:19:20.830 --> 00:19:24.810 And this change, I don't think this change is particularly bad because, you know, 00:19:24.950 --> 00:19:28.790 the last time this limit was lowered, I think it was 10 sats per vbyte in the 00:19:28.790 --> 00:19:34.610 past or maybe five, and the price has gone up 10,000x. So if you look at 00:19:34.610 --> 00:19:39.390 this, you're going to have to look at it as a DoS, a denial of service 00:19:39.390 --> 00:19:45.110 protection. If the minimum relay is too low, then somebody can just 00:19:45.110 --> 00:19:50.030 cheaply cause you to use a lot of bandwidth, everyone to use a lot of bandwidth. 00:19:50.520 --> 00:19:54.600 And so I think the initial calculation years ago was done on like, okay, if 00:19:54.600 --> 00:19:58.720 somebody spins up a bunch of Amazon nodes and just starts flooding us with random 00:19:58.720 --> 00:20:03.920 data, how much does it cost them versus how much does it cost the ecosystem? 00:20:04.700 --> 00:20:09.940 How much cost does the attacker have and how much resources of the community are 00:20:09.940 --> 00:20:14.080 they wasting if you add up everybody's node costs? And so I think we're still 00:20:14.080 --> 00:20:17.660 quite on the safe side of that equation. It's really expensive. 00:20:18.920 --> 00:20:23.940 For the attacker, they need to spend quite a lot of sats to cause people to use bandwidth. 00:20:25.310 --> 00:20:31.130 Yeah, okay. One last note on this point, because I noticed that 00:20:31.130 --> 00:20:37.030 in the GUI, that change, yeah, so in the user interface, that 00:20:37.030 --> 00:20:42.790 change does not apply. Like the minimum fee if you want to send the transaction 00:20:42.790 --> 00:20:44.830 is still the same as it ever was, right? 00:20:45.270 --> 00:20:49.960 Technically, it's the wallet that's unaffected. So the wallet can be used from 00:20:49.960 --> 00:20:53.800 the command line. You'd be surprised some people use it from the command line and 00:20:53.800 --> 00:20:54.360 they like it. 00:20:56.860 --> 00:21:02.640 But yeah, as far as I know, the wallet still has one sat per vbyte as a minimum. 00:21:02.880 --> 00:21:08.150 I think you can manually set it lower. But my guess is the wallet will follow 00:21:08.150 --> 00:21:13.970 in a later release. You kind of want to make sure that the network actually 00:21:13.970 --> 00:21:18.890 relays your transaction, because let's say we change the wallet now to use this 0 00:21:18.890 --> 00:21:24.750 .1 sat per vbyte, and you start your GUI, and you have maybe five peers, and 00:21:24.750 --> 00:21:29.520 none of them have this custom setting. Because, you know, a lot of people do, but 00:21:29.520 --> 00:21:33.080 not everybody does. So you might not be connected to anyone who does. So you sent 00:21:33.080 --> 00:21:37.560 your 0.1 sats per vbyte transaction and it just gets rejected by your peers. And 00:21:37.560 --> 00:21:41.850 they don't tell you it's rejected. So you just, you send it, you close your 00:21:41.850 --> 00:21:44.870 wallet, you go to sleep and the next morning you're like, why isn't this 00:21:44.870 --> 00:21:48.170 confirmed yet? It's because it never went anywhere because you only had your node 00:21:48.170 --> 00:21:52.130 open for five minutes and none of your peers accepted your transaction. So you 00:21:52.130 --> 00:21:55.930 kind of want to be a bit conservative when it comes to the wallet. But I think 00:21:55.930 --> 00:21:57.710 you can just do it manually if you want to. 00:21:58.120 --> 00:22:03.680 Right, so in that sense, Bitcoin Core actually also adjusts to the situation on 00:22:03.680 --> 00:22:08.460 the network. It will only be implemented in the wallet once there's a good enough 00:22:08.460 --> 00:22:11.920 likelihood that it will actually make its way through the network. 00:22:12.480 --> 00:22:15.920 Yeah, and of course there's also a bottleneck of just the very small number of 00:22:15.920 --> 00:22:19.620 people that work on the wallet in general in Bitcoin Core. I don't think we've 00:22:19.620 --> 00:22:24.480 adjusted the new RBF... I don't think we've adjusted to the new RBF reality yet, 00:22:24.480 --> 00:22:24.900 for example. 00:22:26.820 --> 00:22:28.020 And there's some... 00:22:27.730 --> 00:22:28.430 How so? 00:22:29.910 --> 00:22:32.430 You can use RBF with Bitcoin Core, right? 00:22:33.590 --> 00:22:38.190 Yeah, well, Bitcoin Core wallet has been setting the RBF flag for wallet 00:22:38.190 --> 00:22:42.690 transactions for many years. We don't have to anymore because it's gone. 00:22:43.230 --> 00:22:45.610 But there's also no harm in doing it, I guess. 00:22:46.210 --> 00:22:49.230 No, and well, there's actually harm in turning it off. 00:22:49.850 --> 00:22:50.330 Privacy? 00:22:51.150 --> 00:22:55.130 Yeah, you can see who upgraded if we change this. And maybe something similar 00:22:55.130 --> 00:22:58.430 applies to fee rates. If we suddenly drop it, then you can see who is upgraded. 00:22:59.150 --> 00:23:01.130 So I'm not sure what the right path is there. 00:23:01.730 --> 00:23:05.070 Right. Okay, let's move on to the next point. 00:23:05.550 --> 00:23:05.950 Cool. 00:23:06.570 --> 00:23:12.150 Actually, I think this is also, there's another policy issue. There's a new 00:23:12.150 --> 00:23:15.450 policy rule, just correct me if I'm saying anything wrong, but there's a new 00:23:15.450 --> 00:23:20.490 policy rule that restricts the number of signature operations, sigops. 00:23:20.960 --> 00:23:24.020 Per transaction? Or no, per output, right? 00:23:24.520 --> 00:23:29.520 Yeah. So we did a whole episode, 93, about the great consensus cleanup 00:23:29.520 --> 00:23:34.940 restoration soft fork proposal, which deals with time warp attacks. And one of 00:23:34.940 --> 00:23:39.980 the attacks that soft fork, proposed soft fork, is trying to deal with is... 00:23:40.560 --> 00:23:44.280 preventing somebody from making a transaction that takes like an hour and a half 00:23:44.280 --> 00:23:48.500 on a Raspberry Pi. Oh, sorry, to create a block that takes an hour and a half on 00:23:48.500 --> 00:23:53.740 a Raspberry Pi to validate. And maybe several minutes on a modern computer. 00:23:54.220 --> 00:23:58.380 Because if a malicious miner produces such a block, 00:23:58.950 --> 00:24:03.810 they can stall their competition and maybe get a head start out of that. 00:24:06.190 --> 00:24:12.190 And the way that was fixed involves that particular rule. So there's 2,500 00:24:12.190 --> 00:24:16.030 sigops limit per, I think it's per transaction. 00:24:18.340 --> 00:24:24.140 Okay, but just explain what it is. It means basically, if I understand 00:24:24.140 --> 00:24:29.140 correctly, you can make a transaction or an output with what? So you're not sure 00:24:29.140 --> 00:24:31.520 which of the two it is? It's either a transaction or an output? 00:24:31.520 --> 00:24:32.680 I think it's... 00:24:34.010 --> 00:24:38.590 It's per transaction, but what you're counting is you're counting sigops in the 00:24:38.590 --> 00:24:39.810 inputs and in the outputs. 00:24:41.000 --> 00:24:46.340 Okay, so there can be a maximum of 2,500 signatures, basically, in a transaction 00:24:46.340 --> 00:24:47.880 then, right? That's what it means. 00:24:48.240 --> 00:24:51.040 Yeah, signature operations is slightly different. So, for example, 00:24:52.680 --> 00:24:58.540 a legacy multisig or bare multisig, 00:24:58.580 --> 00:25:04.440 as we called it, I think it counts as 20. Something like that. I'm a little fuzzy 00:25:04.440 --> 00:25:07.620 on the details here, but basically it's a limit in the number of signature 00:25:07.620 --> 00:25:12.740 operations. No sane transaction would actually go over those limits. Like there’s no... 00:25:12.500 --> 00:25:14.780 Because it's thousands, yeah. 00:25:15.320 --> 00:25:20.200 Yeah, exactly. You'd need a very, very insane kind of multisig. So the only 00:25:20.200 --> 00:25:23.600 people who would be making such a transaction are people trying to DoS the 00:25:23.600 --> 00:25:27.460 network or people doing experiments. I think there were some historical examples 00:25:27.460 --> 00:25:30.600 of these actually violating them. 00:25:32.350 --> 00:25:37.270 Okay, so right now, if you make a transaction with 3,000 sigops, 00:25:37.750 --> 00:25:43.590 it can still be mined in a block. It is still 00:25:43.590 --> 00:25:44.790 consensus valid, correct? 00:25:44.950 --> 00:25:48.270 Yeah, and that doesn't change, right? This is a policy change. The only thing 00:25:48.270 --> 00:25:49.750 changes is you can't relay it anymore. 00:25:50.750 --> 00:25:55.090 Right. So if someone sends a transaction like that to you and you're running 00:25:55.090 --> 00:25:58.590 Bitcoin Core 30, then you're going to not include that in your mempool and not 00:25:58.590 --> 00:26:02.590 relay it to other nodes. But if it's in a block, again, then that's still fine. 00:26:03.290 --> 00:26:06.710 Yeah. And this is there to protect future miners. It's not really there to 00:26:06.710 --> 00:26:10.610 protect the network because I don't think they're that terrible. 00:26:13.410 --> 00:26:18.890 A future miner, when and if, or if and when this becomes a soft fork, 00:26:19.130 --> 00:26:23.670 then it is consensus. And we don't want a miner to accidentally mine this thing. 00:26:23.990 --> 00:26:28.630 And so that's one of the reasons, one of the goals of policy rules is to prevent 00:26:28.630 --> 00:26:32.760 accidentally mining something. Because the miner doesn't accept it as a standard 00:26:32.760 --> 00:26:34.700 transaction, they'll never see it, they'll never mine it. 00:26:35.160 --> 00:26:40.260 Right, so it's kind of in anticipation of hopefully, potentially a future soft 00:26:40.260 --> 00:26:46.120 fork to already sort of, you know, push network behavior kind of in that 00:26:46.120 --> 00:26:50.780 direction so that when the soft fork happens, then it's a relatively small change 00:26:50.780 --> 00:26:53.640 that can't really cause too much problems essentially, right? 00:26:54.560 --> 00:26:58.520 Yeah, exactly. You want soft forks to be as safe as possible for users, but also 00:26:58.520 --> 00:26:59.000 for miners. 00:26:59.550 --> 00:27:04.710 Yeah, and I think also, so that ties in with, I guess, another point. We do 00:27:04.710 --> 00:27:10.230 apparently keep getting back a little bit to the OP_RETURN issue. As a general 00:27:10.230 --> 00:27:15.770 sort of direction, I think the goal of the Bitcoin Core project is to 00:27:15.770 --> 00:27:21.120 essentially... you know, as much as possible, just get rid of policy rules and 00:27:21.120 --> 00:27:26.940 make what nodes accept and relay as close as possible to the actual consensus 00:27:26.940 --> 00:27:28.200 rules. Is that correct? 00:27:28.320 --> 00:27:33.320 There is a philosophy that says that policy and consensus should converge. 00:27:33.600 --> 00:27:34.620 Yeah, exactly. 00:27:34.940 --> 00:27:40.930 I don't know if that's realistic, but... And one of the reasons is that 00:27:40.930 --> 00:27:46.910 one of the use cases for policy is upgrades, upgrade hooks. 00:27:47.910 --> 00:27:53.770 Upgrade hooks means that, say, SegWit version 2 or 3 or 4 currently is 00:27:53.770 --> 00:27:58.270 not standard, so it will not be relayed. But it is consensus valid. It's just 00:27:58.270 --> 00:28:04.240 that if you mine it, it has no meaning. So that's a case where we don't want them 00:28:04.240 --> 00:28:06.780 to be the same because you would simply never be able to upgrade. 00:28:08.240 --> 00:28:08.840 Sure, yeah. 00:28:09.320 --> 00:28:13.700 So I get the philosophy of like, you don't want to have these pedantic limits, as 00:28:13.700 --> 00:28:19.040 some people would call them, like the OP_RETURN size or RBF things. But it's not, 00:28:19.140 --> 00:28:23.330 I don't think it's true that... consensus and policy cannot be identical because 00:28:23.330 --> 00:28:25.250 you would never be able to upgrade Bitcoin anymore. 00:28:25.790 --> 00:28:27.940 Yeah, you still got to leave the room for... 00:28:28.230 --> 00:28:31.050 Or you'd make it, depending on how, you could also say, well, you'd make it 00:28:31.050 --> 00:28:36.590 completely unsafe. So you could also say, well, let's just allow SegWit version 3 00:28:36.590 --> 00:28:40.990 relay and not worry about it. But then people can shoot themselves in the foot 00:28:40.990 --> 00:28:46.540 and give away their money because you would get a bc1f address. 00:28:47.180 --> 00:28:50.140