WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.060 --> 00:00:12.740 Live from Utrecht, this is the Van Wirdum Sjorsnado. Hello. Sjors, welcome. 00:00:13.080 --> 00:00:13.620 Thank you. 00:00:15.100 --> 00:00:18.300 We're going to pretend that this is the first attempt at recording. 00:00:18.740 --> 00:00:22.580 Nothing went wrong before this. Everything's been going fine so far. That's what 00:00:22.580 --> 00:00:23.540 we're going to act like. 00:00:24.860 --> 00:00:30.600 Yeah, okay, so for context, guys, I promised our listeners we're going to improve 00:00:30.600 --> 00:00:36.600 the audio recording every episode. We've just spent, by now, 75 00:00:36.600 --> 00:00:42.260 minutes trying to get the audio right. I think we finally managed a workable 00:00:42.260 --> 00:00:47.660 solution. It's really unbelievable how hard it is to get this right. Either it's 00:00:47.660 --> 00:00:51.840 just hard to get the software right, and then if we finally get the software 00:00:51.840 --> 00:00:56.170 right, then I'll... Fuck something up for sure. And then we're not recording at 00:00:56.170 --> 00:01:01.250 all. But I think at this point, Sjors, we got it right. We're in a 00:01:01.250 --> 00:01:06.850 situation that it's working well enough that we can sort of 00:01:06.850 --> 00:01:07.270 continue. 00:01:07.270 --> 00:01:09.690 It's just a matter of pushing a button and everything works. 00:01:09.910 --> 00:01:15.650 Okay, let's just go. Let's go. Let's go. Technical stuff, Sjors. Here we go. What 00:01:15.650 --> 00:01:19.230 do you want to talk about? We're going to discuss Taproot. No, last week we 00:01:19.230 --> 00:01:24.460 discussed Taproot. Yep. This week we're going to discuss Taproot activation, or 00:01:24.460 --> 00:01:29.520 more generally, soft fork activation. This has become a topic again in the sort 00:01:29.520 --> 00:01:35.460 of Bitcoin debate, community, public discourse. 00:01:36.490 --> 00:01:41.480 How do we... activate soft forks because Taproot is getting to the point where 00:01:41.480 --> 00:01:47.400 it's sort of you know ready to be deployed almost I think so now the next 00:01:47.400 --> 00:01:51.860 question is okay how are we actually gonna activate this this has been an issue 00:01:51.860 --> 00:01:53.580 in the past with several soft forks 00:01:55.970 --> 00:02:01.530 And it came up in the mailing list, I think, a couple of months ago. And now it's 00:02:01.530 --> 00:02:07.270 sort of re-emerged. There's now an IRC channel where it's being debated. 00:02:07.470 --> 00:02:10.970 There's a Telegram channel. I wrote an article on it. It's back on the dev list. 00:02:13.620 --> 00:02:17.720 yeah i read the whole irc channel no actually i started reading the irc channel i 00:02:17.720 --> 00:02:20.920 got stuck at the meta discussion about whether or not there should be a telegram 00:02:20.920 --> 00:02:24.040 channel and whether or not you need to ask permission and whether or not asking 00:02:24.040 --> 00:02:28.320 permission was off topic in the irc channel and after an hour i gave up and you 00:02:28.320 --> 00:02:30.300 spent your entire saturday i believe 00:02:30.300 --> 00:02:34.240 i spent most of my saturday reading for all of the logs and sort of trying to 00:02:34.240 --> 00:02:39.780 summarize it into an article yes yeah i i didn't read past saturday so if there 00:02:39.780 --> 00:02:44.260 was any sort of big discussion or development since Saturday, I might be out of 00:02:44.260 --> 00:02:50.000 the loop a little bit, but that wasn't really my impression. I think I covered 00:02:50.000 --> 00:02:53.420 most of it, so I think we can cover most of it in the podcast as well. 00:02:53.640 --> 00:02:55.860 So maybe we should say what a soft fork is. 00:02:55.860 --> 00:02:57.740 Let's start there. What is a soft fork, Sjors? 00:02:58.100 --> 00:03:03.220 So it's basically a tightening of the rules. An analogy I like to make is with 00:03:03.220 --> 00:03:06.240 kosher food. I've made this analogy three times. 00:03:06.440 --> 00:03:09.500 Yes, this is the third time you're making the analogy because we're recording 00:03:09.500 --> 00:03:14.000 this start of the podcast for the first time, which is annoying. But let's just go on. 00:03:14.000 --> 00:03:17.880 Basically, kosher food is a subset of regular food. So there's a few things you 00:03:17.880 --> 00:03:22.550 don't eat. So often you might not notice it. There's a lot of soft drinks that 00:03:22.550 --> 00:03:26.150 are kosher and you wouldn't know the difference. But sometimes you would know the 00:03:26.150 --> 00:03:29.130 difference and that could be a problem. But with Bitcoin, there is no such 00:03:29.130 --> 00:03:34.050 problem. Because the things that are no longer allowed after soft fork are very 00:03:34.050 --> 00:03:34.810 stupid things. 00:03:35.210 --> 00:03:40.290 So hang on. The thing you're saying is that soft fork is backwards compatible in 00:03:40.290 --> 00:03:43.550 the context of Bitcoin. And the reason for that is like, let's say I go to a 00:03:43.550 --> 00:03:47.320 restaurant every day because I love the food there. and then one day they 00:03:47.320 --> 00:03:53.030 introduce kosher food and the food is still great I can still go there because I 00:03:53.030 --> 00:03:58.150 don't care if it's kosher or not. So there's tighter rules. I didn't care about 00:03:58.150 --> 00:04:00.270 whether or not it's kosher, so it's fine for me. 00:04:00.390 --> 00:04:04.490 But you would if your favorite recipe was now kicked out of the restaurant. 00:04:04.690 --> 00:04:07.970 I would care if they get bacon out of the... 00:04:07.970 --> 00:04:13.490 Exactly. But this is not the case the way Bitcoin soft forks works. So they 00:04:13.490 --> 00:04:17.710 wouldn't remove your bacon, basically. They would remove your ability to stab 00:04:17.710 --> 00:04:23.660 yourself, basically. And so it's a nice and elegant way to make the rules more 00:04:23.660 --> 00:04:28.620 strict without suddenly freezing anybody's coins. So normal people can keep using 00:04:28.620 --> 00:04:34.200 it. They don't have to upgrade. They can keep using the old rules if they want to. 00:04:36.360 --> 00:04:41.920 An exchange can basically ignore SegWit for years, and it's perfectly fine, as 00:04:41.920 --> 00:04:42.940 far as the blockchain is concerned. 00:04:44.250 --> 00:04:47.370 I guess we can talk about some examples. 00:04:49.470 --> 00:04:54.130 So Satoshi introduced soft forks in the very beginning in a way that we wouldn't 00:04:54.130 --> 00:04:58.310 do anymore. Basically, one of the things he did was introduce a one megabyte 00:04:58.310 --> 00:05:03.860 limit. There was no limit. He realized that was bad, dangerous. So he put in the 00:05:03.860 --> 00:05:07.220 limit. And then later on, when it was already active, he said, oh, by the way, 00:05:07.560 --> 00:05:08.280 there's a limit. 00:05:08.730 --> 00:05:12.550 Yeah, so that's an interesting example that I didn't mention in my article for 00:05:12.550 --> 00:05:17.770 Bitcoin Magazine, which is... So, I mean, we're going to discuss how to implement 00:05:17.770 --> 00:05:21.570 soft forks, how to upgrade the protocol. And one of the examples that Satoshi 00:05:21.570 --> 00:05:27.410 used was to basically just snuck it in there. Yeah. And, you know, only once 00:05:27.410 --> 00:05:30.330 people are running the code, they'll figure out that there's now one megabyte 00:05:30.330 --> 00:05:34.970 limit. Right. Which worked at a time, I guess. And maybe it was even a good way 00:05:34.970 --> 00:05:40.950 to do it because in his mind, he was probably fixing like an attack vector. 00:05:41.370 --> 00:05:45.410 Yeah. And in that case, it made sense because you tell people about it and that 00:05:45.410 --> 00:05:48.390 increases the chance of the attack vector being exploited. 00:05:48.870 --> 00:05:54.020 Right. But it can also happen by accident. You accidentally add a rule to the 00:05:54.020 --> 00:05:57.620 system that you didn't know was there. So that sort of stuff could happen, but 00:05:57.620 --> 00:06:00.160 that's not what we're going to talk about. We're going to talk about a deliberate 00:06:00.160 --> 00:06:05.640 change in the rules. And so the other way that was done when there was a new rule 00:06:05.640 --> 00:06:11.020 was a flag day to say basically from this day forward, this new rule shall apply. 00:06:11.380 --> 00:06:15.920 And you announce that plenty of time in advance and then people upgrade and it's all good. 00:06:16.220 --> 00:06:21.190 Yeah. So you have to say like... One year from now, so that's like July 00:06:21.190 --> 00:06:26.630 24th, when this is being published, I think. July 00:06:26.630 --> 00:06:32.370 24th, 2021, that's when the new rules are enacted. Right. Or you say at 00:06:32.370 --> 00:06:37.310 block height, I don't know, some block height in the future, at this point, the 00:06:37.310 --> 00:06:38.570 new rule is enacted. 00:06:38.910 --> 00:06:44.890 Yeah. But there was still a problem there. Which is that you want to 00:06:44.890 --> 00:06:48.630 make sure that everybody's actually running the new software. And especially that 00:06:48.630 --> 00:06:51.870 miners are running the new software. Because they kind of have to enforce those 00:06:51.870 --> 00:06:56.430 new rules. I mean, it's nice if they, it's really nice if they enforce the new rules. 00:06:56.650 --> 00:07:00.890 Well, everyone's enforcing the new rules. Or at least everyone who's upgraded is 00:07:00.890 --> 00:07:05.370 enforcing the new rules. But if a majority of hash power does it, that means they 00:07:05.370 --> 00:07:09.750 always reclaim the longest chain. Even for the non-upgraded nodes, like they 00:07:09.750 --> 00:07:14.880 still consider that a valid chain so then everyone old and new nodes will 00:07:14.880 --> 00:07:18.840 converge on this chain yeah that's why it's very nice if a majority hash power 00:07:18.840 --> 00:07:20.060 enforces the rules as well 00:07:20.060 --> 00:07:25.360 exactly and for miners there's a risk if they if you know a majority of miners 00:07:25.360 --> 00:07:29.380 implement uh enforces the new rules but the minority doesn't they could 00:07:29.380 --> 00:07:30.720 accidentally mine the wrong block 00:07:30.720 --> 00:07:34.940 yeah the minority could mine an invalid block and then have their block orphaned 00:07:34.940 --> 00:07:37.700 exactly they might not even know why if they're not upgraded 00:07:37.700 --> 00:07:38.520 exactly so 00:07:38.520 --> 00:07:43.320 it's nice that miners signal that they're ready to do this upgrade so that, you 00:07:43.320 --> 00:07:46.700 know, you can get an idea, okay, most miners are clearly ready and a few miners 00:07:46.700 --> 00:07:49.140 that are not, well, hopefully they'll be fine. 00:07:49.240 --> 00:07:54.800 So that's sort of the other upgrade strategy apart from just stuffing it in there 00:07:54.800 --> 00:07:59.890 without telling anyone. You have flag days and you have miner activation so 00:07:59.890 --> 00:08:05.670 signaling so the signaling works as a coordination mechanism for the 00:08:05.670 --> 00:08:10.730 network to figure out okay enough miners have upgraded now this signals to 00:08:10.730 --> 00:08:15.790 everyone the network is ready and through this signaling mechanism a date or a 00:08:15.790 --> 00:08:20.770 time or a block height is you know communicated essentially that's embedded in 00:08:20.770 --> 00:08:24.670 the code that if enough signals are included in the blockchain then we all know 00:08:24.670 --> 00:08:28.530 at block height x the new rules will go into effect. 00:08:28.810 --> 00:08:33.610 Exactly. So usually it's every two weeks. You count the number of blocks that 00:08:33.610 --> 00:08:37.990 have the signal. And if it's above a certain threshold, for example, 95%, then 00:08:37.990 --> 00:08:41.250 you know that two weeks later, the new rule is active. 00:08:41.610 --> 00:08:46.090 Yes, that was BIP9, which you're explaining now. The Bitcoin improvements 00:08:46.090 --> 00:08:51.880 proposal 9. uses this difficulty period, 00:08:52.220 --> 00:08:53.360 95%. 00:08:53.360 --> 00:08:57.520 So these are the three main mechanisms, right? You can just randomly do this, you 00:08:57.520 --> 00:09:01.260 can announce a date, and you can have miners signal up to a certain threshold. 00:09:01.600 --> 00:09:05.840 And now the question is, what are you going to do for taproot, and what have we 00:09:05.840 --> 00:09:08.500 done in the past? And maybe you want to combine some of these methods. 00:09:08.800 --> 00:09:11.300 Yeah, well, should we mention why BIP9 is a problem? 00:09:13.100 --> 00:09:18.420 Well, so BIP9 was used a couple of times to deploy some features, I believe. 00:09:19.420 --> 00:09:24.480 But when it was time to deploy SegWit, it took a long time. 00:09:25.200 --> 00:09:30.100 We don't know if it would have happened eventually, but at least for, I think, at 00:09:30.100 --> 00:09:35.100 least half a year or so that the code was ready, it just didn't activate. Only a 00:09:35.100 --> 00:09:38.900 small percentage of miners was signaling for it, or at least not the 95%. 00:09:38.900 --> 00:09:44.310 Yes, but we have a pretty good idea why that was. I mean, at least the miners 00:09:44.310 --> 00:09:47.930 that were blocking it were telling us why they were blocking it. 00:09:48.110 --> 00:09:52.890 Yes, exactly. I mean, it's possible that some miners were just completely not 00:09:52.890 --> 00:09:57.430 interested. Yes, that's all. There was definitely miners that were actively not 00:09:57.430 --> 00:09:58.250 signaling it. 00:09:58.250 --> 00:10:02.270 Yeah, miner apathy. That was probably a factor for at least some miners. Sure. 00:10:02.910 --> 00:10:07.110 So what happened then is a number of different things happened outside the 00:10:07.110 --> 00:10:11.030 blockchain. There was basically a group of people that said, hey, you know what? 00:10:11.390 --> 00:10:14.350 We're just going to, instead of the signaling, we're just going to go back to the 00:10:14.350 --> 00:10:19.870 old flag day approach. And that was called BIP-148. So they picked April 1st, 00:10:19.970 --> 00:10:24.790 2017 and basically said, well, our nodes are now going to enforce these rules. 00:10:25.790 --> 00:10:31.770 Yeah, but hang on. So to explain this real quick, the downside of BIP 00:10:31.770 --> 00:10:35.750 -9 was that miners were blocking the upgrade because they wanted either political 00:10:35.750 --> 00:10:40.920 leverage or they were secretly benefiting. from something that the upgrade would 00:10:40.920 --> 00:10:45.180 have fixed without telling anyone that that was the case or both like but there 00:10:45.180 --> 00:10:50.460 were bad reasons basically for the miners to block this upgrade and this made 00:10:50.460 --> 00:10:55.440 Bitcoin Core developers and other Bitcoiners realize that okay there's actually 00:10:55.440 --> 00:11:01.220 kind of a downside to BIP9 because it gives miners this leverage which they 00:11:01.220 --> 00:11:05.390 shouldn't have at all like they're treating it like a vote. And they're sort of 00:11:05.390 --> 00:11:10.910 abusing their vote in ways that's bad. While it's not even meant to be a vote, 00:11:10.930 --> 00:11:12.810 it's just meant to be a coordination mechanism. 00:11:13.050 --> 00:11:18.650 Exactly. And also the reasons why you might want to oppose a proposal 00:11:18.650 --> 00:11:23.730 generally should be technical in nature and not political. Yes. 00:11:24.920 --> 00:11:26.220 So, I guess that. 00:11:26.380 --> 00:11:31.080 Yeah, so ultimately, and this is what you were getting at, this was resolved in 00:11:31.080 --> 00:11:35.780 some way or another, and there's still debate to this day how it was resolved 00:11:35.780 --> 00:11:36.880 exactly. Right, 00:11:37.140 --> 00:11:41.980 because two things happened at the same time, right? You had the BIP-148 UASF 00:11:41.980 --> 00:11:44.640 rules, the guys with the guns and the nodes. 00:11:45.420 --> 00:11:48.120 Or with the hats. I don't think they had guns, but they had hats. 00:11:48.140 --> 00:11:48.800 One of them had guns. 00:11:49.690 --> 00:11:53.110 Oh, yeah. Yeah, that's true. I think they were like... 00:11:53.110 --> 00:11:54.290 Defending the Bitcoin. 00:11:54.510 --> 00:11:58.050 Yes, that's true. That's true. And I think Tone Vays had like a knife. 00:11:58.530 --> 00:12:03.170 And... And so then the question is, you know, you can tell if you read all the 00:12:03.170 --> 00:12:07.650 social media and the mailing list that that obviously played a role. But if you 00:12:07.650 --> 00:12:12.570 just look at the blockchain, you can't really tell because what you see on the 00:12:12.570 --> 00:12:17.250 blockchain is all of a sudden 95% started signaling and the thing activated. 00:12:17.590 --> 00:12:21.690 Sure. Now, it's, of course, very remarkable that this activated exactly before 00:12:21.690 --> 00:12:26.350 August 1st and not some random other date that it could have happened. But there 00:12:26.350 --> 00:12:30.470 were no blocks rejected that we could still point at saying, hey, look, there was 00:12:30.470 --> 00:12:35.810 actually a fight between miners, etc. At the same time, there was an initiative 00:12:35.810 --> 00:12:40.750 from the New York Agreement Group. And they had a whole bunch of things that they 00:12:40.750 --> 00:12:46.610 were planning to do. But one thing they were doing is called BIP 91. And they 00:12:46.610 --> 00:12:50.750 would basically lower the threshold. So they said instead of having 95%, we're 00:12:50.750 --> 00:12:52.070 just going to accept 75%. 00:12:53.400 --> 00:12:58.960 Yeah, well, to be a little bit more precise, what they did in the end was use 00:12:58.960 --> 00:13:04.840 75% forced signaling. So it was like BIP-148, but it 00:13:04.840 --> 00:13:08.040 was like a soft fork to activate a soft fork. 00:13:08.240 --> 00:13:13.770 Yeah, so basically you had to signal that you were going to act... that you were 00:13:13.770 --> 00:13:14.810 going to activate the soft fork. 00:13:15.170 --> 00:13:15.330 Yes. 00:13:15.590 --> 00:13:18.790 And then because there was more signaling, it would activate. But that, again, 00:13:19.010 --> 00:13:22.330 you cannot tell from the chain because immediately people started signaling at 00:13:22.330 --> 00:13:26.510 95%. And so that's the nice thing about these kind of situations. You can't 00:13:26.510 --> 00:13:30.430 really tell what happened. It didn't go wrong. Nobody called each other's bluff. 00:13:31.530 --> 00:13:35.470 Yes, and I think everyone agrees that it was at least sort of a tense period. 00:13:37.290 --> 00:13:43.110 It showed everyone that maybe we've got to rethink 00:13:43.110 --> 00:13:46.790 how we're actually going to do soft forks because this was very close to becoming 00:13:46.790 --> 00:13:47.870 a huge mess. 00:13:48.110 --> 00:13:51.310 If you think through the worst case scenarios, which I guess we'll just avoid now 00:13:51.310 --> 00:13:55.470 because it'll get too confusing, but if you have chain splits, and especially if 00:13:55.470 --> 00:13:59.320 you have multiple chain splits with people... people having different opinions 00:13:59.320 --> 00:14:02.760 about what the blockchain should be that kind of defeats the purpose of a well 00:14:02.760 --> 00:14:04.880 -functioning blockchain so it's something you want to avoid 00:14:04.940 --> 00:14:10.800 yes yes and let's skip the details but it would have um there 00:14:10.800 --> 00:14:15.420 was a risk of it becoming a pretty big mess i think that we we both agree on 00:14:15.420 --> 00:14:19.260 I was worried for quite a while it would be an absolute clusterfuck. yes 00:14:19.260 --> 00:14:24.830 so new ideas how are we gonna How are we going to think about soft forks 00:14:24.830 --> 00:14:26.950 and soft fork activation from now on? 00:14:27.190 --> 00:14:32.690 Well, one thing that was done is a proposal, a revamped proposal called BIP-8. 00:14:33.070 --> 00:14:37.990 And yes, that's a lower number because the proposal was older, but now it's 00:14:37.990 --> 00:14:42.960 actually newer. So that is confusing. But generally, there were just a couple of 00:14:42.960 --> 00:14:48.800 improvements to the original mechanism. Maybe not super interesting. For 00:14:48.800 --> 00:14:51.780 example, using blocks instead of dates. 00:14:52.040 --> 00:14:54.000 Well, explain what BIP8 is in the first place. 00:14:55.080 --> 00:14:58.380 Well, BIP8 was, I think, just a flag date proposal. 00:14:58.740 --> 00:15:00.800 Was it originally just a flag date? 00:15:00.960 --> 00:15:01.560 Yeah, I think so. 00:15:01.780 --> 00:15:06.540 Okay, but later it was definitely, like the idea was that it was... A combination 00:15:06.540 --> 00:15:08.940 of BIP9 and a flag date, basically. 00:15:09.320 --> 00:15:11.980 Right, so what it is now, at least, that's probably the most useful thing to 00:15:11.980 --> 00:15:17.660 describe, is the signaling is still there with some tweaks, but there is also a 00:15:17.660 --> 00:15:19.340 built-in option to have a flag date. 00:15:19.740 --> 00:15:20.120 And 00:15:20.120 --> 00:15:26.080 now BIP is just a sort of a proposal of how you could do things. And so you 00:15:26.080 --> 00:15:29.820 could use the flag date or you could not use the flag date. But the proposal now 00:15:29.820 --> 00:15:33.720 explains, okay, if you have a flag date, this is how you do it. And it's a one 00:15:33.720 --> 00:15:39.520 -way mechanism. So you could propose a new soft fork and not set a flag 00:15:39.520 --> 00:15:44.040 date and then later on set a flag date. But you cannot 00:15:44.040 --> 00:15:49.550 propose a flag date and then unset it, basically. So if you decide on a flag 00:15:49.550 --> 00:15:50.670 date, you better go through with it. 00:15:51.680 --> 00:15:55.480 Well, you can release a new client that doesn't have the flag date, of course. 00:15:55.700 --> 00:15:56.800 Yeah, but now you have a mess. 00:15:57.980 --> 00:16:02.620 Well, one of the nice things about BIP-8 is actually that 00:16:02.620 --> 00:16:08.570 it doesn't have a flag date purely. It has a 00:16:08.570 --> 00:16:14.410 force signaling deadline. So it's kind of like BIP-148 before, 00:16:14.630 --> 00:16:19.170 where... If you have the flag date on, so let's just call it the flag date for 00:16:19.170 --> 00:16:24.410 now, then it doesn't mean that it activates the soft fork itself. It means 00:16:24.410 --> 00:16:30.050 that... If near the end, any block that's not mining 00:16:30.050 --> 00:16:35.830 activation, not mining support for the soft fork, that block will be orphaned. 00:16:36.350 --> 00:16:41.970 So it forces signaling towards the end. So this means that if you have two 00:16:41.970 --> 00:16:47.550 groups of BIP8 nodes, one of them has the force signaling on and one of them has 00:16:47.550 --> 00:16:52.620 the force signaling off. But miners go along with the force signaling on. then 00:16:52.620 --> 00:16:56.200 the nodes that have forced signaling off will still accept the soft fork because 00:16:56.200 --> 00:16:58.200 they're still seeing... 00:16:58.200 --> 00:16:58.900 They're still seeing the signaling. 00:16:59.120 --> 00:17:05.040 Yes, exactly. So that's a slight change from previous BIP-8. 00:17:05.480 --> 00:17:11.240 Yeah. And I forgot whether... I think you still need to... If you have a 00:17:11.240 --> 00:17:14.940 flag date in mind, you may still need to put it in there because you don't want 00:17:14.940 --> 00:17:19.640 different people to have different flag dates. So I guess it doesn't matter if 00:17:19.640 --> 00:17:24.170 you force signaling, but... It just becomes a mess because if you force people to 00:17:24.170 --> 00:17:29.990 signal and then they don't signal and you just decide to not accept all their 00:17:29.990 --> 00:17:35.630 blocks, if only a small number of people do that, then you still get a mess. So 00:17:35.630 --> 00:17:39.430 I don't think it's completely thought out, but it's definitely... You probably 00:17:39.430 --> 00:17:42.650 still want to have some consensus. If you decide on the flag date, you want to 00:17:42.650 --> 00:17:46.770 have a very large consensus on what that flag date is and that really everybody 00:17:46.770 --> 00:17:47.570 goes along with it. 00:17:48.620 --> 00:17:54.480 but maybe i mean it depends right like if even if you don't have consensus but 00:17:54.480 --> 00:18:00.260 at least miners don't don't want to see splits or they like it they could play it 00:18:00.260 --> 00:18:04.350 safe. that's sort of how BIP 148 happens right 00:18:04.350 --> 00:18:09.370 yeah but now imagine if you had two different like one you had the august 1 group 00:18:09.370 --> 00:18:14.960 and you had the august 15 group And maybe it didn't activate at August 1, but 00:18:14.960 --> 00:18:18.940 some major exchanges decided to join the August 1 group, and some other major 00:18:18.940 --> 00:18:23.720 exchanges decided to join the August 15 group. So it would still be a mess. 00:18:24.080 --> 00:18:27.900 Yes, the assumption is that in that case, or the hope is that in that case, 00:18:28.060 --> 00:18:31.560 miners just go for the August 1 one, so they don't split the network. 00:18:31.760 --> 00:18:35.520 That's one option. But I think at least an improvement here is that, let's say 00:18:35.520 --> 00:18:36.700 you just have miner apathy. 00:18:38.220 --> 00:18:43.200 You thought you can get 95% signaling, but there's apathy. You can have another 00:18:43.200 --> 00:18:46.460 discussion on mailing lists, and everybody says, yeah, yeah, we're fine with this 00:18:46.460 --> 00:18:50.880 upgrade, and no miners objecting to it. They're just not bothering to upgrade 00:18:50.880 --> 00:18:56.880 their software to signal. Then you can calmly agree on a date as a flag date and 00:18:56.880 --> 00:19:01.760 just calmly add it, and there's not going to be too much chaos. But you still 00:19:01.760 --> 00:19:04.180 have the problem of the miners not enforcing the rules. 00:19:05.150 --> 00:19:10.090 okay so i think these are sort of the basics of BIP 8 and the next 00:19:10.090 --> 00:19:15.230 thing is that you can sort of play around with the parameters in all sorts of way 00:19:15.230 --> 00:19:20.990 so we've already mentioned with or without flag day and the flag day in turn 00:19:20.990 --> 00:19:26.420 can be an actual flag day or force signaling then you can play around with like a 00:19:26.420 --> 00:19:31.200 parameter of how long how far into the future should this flag day be yeah you 00:19:31.200 --> 00:19:37.020 can play with the parameter of how much hash power do you need so so far we've 00:19:37.020 --> 00:19:43.000 mentioned 95% but you could lower this you could say 75% is enough 50% 00:19:43.000 --> 00:19:48.130 is enough even one percent is enough you could potentially do that right yeah 00:19:48.130 --> 00:19:49.810 that's pretty useless but you could yeah 00:19:49.810 --> 00:19:54.090 i i agree but like the point is you can play around with this parameters in all 00:19:54.090 --> 00:19:57.910 sorts of ways so now you sort of have pieces of the puzzle and then you can think 00:19:57.910 --> 00:20:03.670 of ways to put these pieces together to come up with like a concrete 00:20:03.670 --> 00:20:08.250 activation strategy that we're going to use for taproot yeah but you 00:20:08.250 --> 00:20:12.370 can also imagine that there's going to be a lot of permutations and so this could 00:20:12.670 --> 00:20:14.950 It could be a bike-shedding nightmare. Yes. 00:20:16.940 --> 00:20:22.560 Yes, it could. But shall we cover some of them? Some of the sort of general ideas 00:20:22.560 --> 00:20:23.480 that are floating around? 00:20:23.720 --> 00:20:24.000 Yeah, sure. 00:20:24.720 --> 00:20:27.840 Okay, so one idea that has been proposed by Matt Corallo, 00:20:29.140 --> 00:20:34.800 a well-known core contributor, he calls it modern soft fork activation. 00:20:35.950 --> 00:20:41.950 So what he proposes is, let's use BIP-8 without forced signaling 00:20:41.950 --> 00:20:46.530 on the end or without forced activation on the end for a year. So that's more 00:20:46.530 --> 00:20:52.490 like BIP-9. That's what we used to do. See if miners activate it, just 00:20:52.490 --> 00:20:57.330 requiring a 95% hash power support threshold. 00:20:57.970 --> 00:21:03.380 Let's see if they do it or not. If they do it, great, 00:21:03.920 --> 00:21:08.680 soft fork has been activated. If they don't, then phase two of this proposal 00:21:08.680 --> 00:21:13.960 comes into play, which is six months of developer 00:21:13.960 --> 00:21:19.740 reconsideration. So developers see if there was a good reason for 00:21:19.740 --> 00:21:24.310 miners to block it. Maybe there was a problem with a proposal, in this case, 00:21:24.330 --> 00:21:29.710 Taproot, that they hadn't considered before. So developers are just going to sort 00:21:29.710 --> 00:21:34.930 of reconsider. If after six months they haven't found anything wrong with the 00:21:34.930 --> 00:21:39.610 proposal and they concluded that, okay, it's actually just miner apathy or miner— 00:21:39.610 --> 00:21:44.730 miners, you know, trying something or whatever, like no good reason, then we're 00:21:44.730 --> 00:21:50.320 going to deploy it again. This time, you know, BIP8 with... 00:21:50.300 --> 00:21:52.740 Either force signaling or... 00:21:52.740 --> 00:21:54.870 With a flag day. 00:21:55.030 --> 00:21:59.710 Flag day on the end. I think Matt's original idea was flag day on the end, but 00:21:59.710 --> 00:22:02.230 he's probably open to force signaling, I would imagine. 00:22:02.450 --> 00:22:05.990 I mean, the question is, if you have a flag day, what do you do on the flag day? 00:22:06.210 --> 00:22:09.730 And one thing you can do with a flag day is enforce the soft fork, and the other 00:22:09.730 --> 00:22:13.210 is you can force the signaling, which then triggers the soft fork. Well, exactly. 00:22:13.390 --> 00:22:18.000 So I don't think that's more of a detail. And it's probably not controversial to 00:22:18.000 --> 00:22:20.480 force the signaling instead of forcing the soft fork. 00:22:20.600 --> 00:22:22.300 Yeah, I think that wouldn't be very controversial. 00:22:22.600 --> 00:22:24.860 It just makes it more compatible with what other people are doing. 00:22:25.040 --> 00:22:29.560 Yes, exactly. So that would probably be, yeah. Okay, so that's one idea. 00:22:31.080 --> 00:22:36.980 It has, you know, the benefits of sort of taking it easy and reconsidering 00:22:36.980 --> 00:22:40.440 if there's maybe something wrong with the proposal. And if there is something 00:22:40.440 --> 00:22:44.470 wrong with the proposal, then people don't have to actually... need to upgrade 00:22:44.470 --> 00:22:47.670 their software they can just you know keep running whatever they were running 00:22:47.670 --> 00:22:52.270 yeah because um there was a timeout anyway in the software it just didn't happen 00:22:52.270 --> 00:22:57.250 and it's sort of fine there's no no sort of emergency upgrades needed at all or 00:22:57.250 --> 00:23:02.930 anything like that yeah um the downside is that if miners don't cooperate it's 00:23:02.930 --> 00:23:08.130 going to take a long time before the soft fork actually is live on network like 00:23:08.130 --> 00:23:12.740 three and a half years yeah So that means app developers have to wait three and a 00:23:12.740 --> 00:23:17.880 half years. Everyone's just sort of stuck waiting for three and a half years for 00:23:17.880 --> 00:23:22.100 basically no good reason. So that's why some people really don't like this 00:23:22.100 --> 00:23:22.540 proposal. 00:23:22.960 --> 00:23:23.140 Yeah. 00:23:23.520 --> 00:23:24.200 What do you think? 00:23:24.500 --> 00:23:28.680 Well, you've got to think in the long run, right? So it's nice if you can have 00:23:28.680 --> 00:23:33.560 these improvements shipped very quickly. But if there is a tradition that 00:23:33.560 --> 00:23:38.400 developers decide on a soft fork and it gets activated quickly, well then... 00:23:38.880 --> 00:23:42.680 Maybe a government starts calling developers and saying, hey, we have this KYC 00:23:42.680 --> 00:23:47.580 soft fork. And since nobody really pays attention and miners run anything you 00:23:47.580 --> 00:23:51.920 want, why don't you just make that soft fork and don't worry about the review 00:23:51.920 --> 00:23:56.020 process? So you don't want to put too much power in the hands of the developers. 00:23:56.020 --> 00:23:59.180 They don't want that kind of power because it means they're going to get very 00:23:59.180 --> 00:24:01.080 unpleasant phone calls at some point. 00:24:02.730 --> 00:24:06.850 You know, it's a difficult trade-off because on the time scale of 200 years, it 00:24:06.850 --> 00:24:10.810 really doesn't matter if the soft fork takes three years longer. But we have no 00:24:10.810 --> 00:24:14.310 idea what the right time is. You know, maybe it makes no difference for this 00:24:14.310 --> 00:24:18.910 political problem. It might really just be wasting three years. Or it's really 00:24:18.910 --> 00:24:20.490 important to make sure there's no problem. 00:24:22.130 --> 00:24:26.990 So I'd like to see it deployed soon and hopefully miners are excited. But it's 00:24:26.990 --> 00:24:31.150 going to get more and more difficult to deploy these things in general because if 00:24:31.150 --> 00:24:35.490 you get, and we want that, lots and lots of very small individual mining pools, 00:24:35.710 --> 00:24:39.870 well, trying to get 95% even just to communicate to them is going to be harder. 00:24:40.670 --> 00:24:43.610 And that's a good thing, but it could slow things down very. 00:24:43.990 --> 00:24:49.830 Sure. So another idea is BIP-8. um let's say with like a year 00:24:49.830 --> 00:24:55.410 deadline at which time force signaling happens almost kind of like a basic 00:24:55.410 --> 00:25:01.030 proposal would it be so to first ask you about that do you think that's too fast 00:25:01.030 --> 00:25:01.690 one year 00:25:01.690 --> 00:25:07.610 so my problem with the force signal is if you if you [unclear] if you ship this 00:25:07.610 --> 00:25:11.690 thing and you say okay miners can signal for it but but if they don't it's going 00:25:11.690 --> 00:25:17.560 to activate you kind of lock yourself into that outcome, there's no real way to 00:25:17.560 --> 00:25:22.540 object anymore. Because even if people have, if miners come up and say, hey, wait 00:25:22.540 --> 00:25:25.920 a minute, there is a problem, then you can't cancel it anymore because people are 00:25:25.920 --> 00:25:30.560 running this new software and they have the force signaling in. So lots of people 00:25:30.560 --> 00:25:34.680 would see their nodes just stop. So you're essentially having a hard fork if you 00:25:34.680 --> 00:25:39.420 decide to not do it. So what I think you should do at minimum is say, we ship 00:25:39.420 --> 00:25:45.090 this version without the hard-coded date in it, but we're probably going to 00:25:45.090 --> 00:25:47.910 enforce that hard-coded date in a new upgrade. 00:25:48.230 --> 00:25:53.290 Yeah, well, that's another proposal, and I want to get there next. Okay. So 00:25:53.290 --> 00:25:58.670 this one I don't like, because if you remove any ability to object, then why even 00:25:58.670 --> 00:26:03.440 bother with the miner signaling? Because once you put a flag date in the code, 00:26:03.580 --> 00:26:06.380 and you ship that code, that's it. It's just going to activate. 00:26:07.170 --> 00:26:08.770 yeah well the idea behind 00:26:08.770 --> 00:26:11.790 unless you force people to upgrade and that's a hard fork 00:26:11.850 --> 00:26:17.850 yeah although the idea behind any soft fork including taproot presumably is 00:26:17.850 --> 00:26:21.250 that there shouldn't be a problem with it if it's going to be shipped at all like 00:26:21.250 --> 00:26:25.770 at the point of it being shipped there shouldn't be any problems with it yeah and 00:26:25.770 --> 00:26:28.370 after that it's just a matter of coordinating the upgrade but 00:26:28.370 --> 00:26:31.550 the question is when are people going to bother to review it and i could imagine 00:26:31.550 --> 00:26:36.250 that if i'm a miner and i'm like i have to run this new version let's see what 00:26:36.250 --> 00:26:39.730 it's doing right holy shit i don't like these new rules why are they reducing the 00:26:39.730 --> 00:26:40.850 block reward right yes 00:26:40.850 --> 00:26:45.370 that's that's one of matt's arguments as well that people and miners will only 00:26:45.370 --> 00:26:49.330 really consider it when the code is out there and the software is out there yeah 00:26:49.330 --> 00:26:53.260 and it's an expensive signal too right from As a developer, you're really 00:26:53.260 --> 00:26:57.060 shipping this software. That's a bigger commitment than saying, okay, looks good 00:26:57.060 --> 00:27:01.720 on GitHub. So I think that is a critical moment, and you can't expect review to 00:27:01.720 --> 00:27:05.400 happen after that or review to happen after that. So that's why I don't think you 00:27:05.400 --> 00:27:09.540 should put the date in stone, at least not the first try, maybe half a year 00:27:09.540 --> 00:27:11.180 later. Maybe you don't have to wait for the whole year. 00:27:11.700 --> 00:27:16.120 Yeah, so a related idea, and it's almost kind of the same idea, I guess, but it's 00:27:16.120 --> 00:27:17.960 Luke Jr. 00:27:19.080 --> 00:27:19.840 Luke Dashjr. 00:27:20.980 --> 00:27:22.760 Yeah, Luke Dashjr, Luke Jr. 00:27:23.120 --> 00:27:26.060 People call him Luke Jr., but he once said in the podcast it's Luke Dashjr. 00:27:26.360 --> 00:27:26.960 Oh, he did? 00:27:27.160 --> 00:27:32.420 Yeah, the Peter McCormack show. That's the first time I learned. Alright. Maybe he's lying. 00:27:33.650 --> 00:27:37.910 No, he's not allowed to lie, according to his religion. Okay. 00:27:40.270 --> 00:27:45.870 He likes BIP-8 with force signaling towards the end, but he 00:27:45.870 --> 00:27:51.850 prefers it to be deployed in... forks for clients so not in 00:27:51.850 --> 00:27:57.130 bitcoin core so kind of like BIP 148 like he thinks soft fork activation should 00:27:57.130 --> 00:28:02.410 happen through different clients that sort of takes away this pressure on bitcoin 00:28:02.410 --> 00:28:08.150 core developers like potential uh you know government uh enforced soft 00:28:08.150 --> 00:28:13.450 forks that sort of stuff so only do it through forks of bitcoin core forked 00:28:13.450 --> 00:28:14.750 clients what do you think of that idea 00:28:14.750 --> 00:28:18.210 well how do you coordinate the date Someone just 00:28:18.210 --> 00:28:23.010 picks one or it's sort of coordinated in some Slack channel, like happened with 00:28:23.010 --> 00:28:24.410