WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.340 --> 00:00:09.960 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.200 --> 00:00:10.420 Hello. 00:00:11.360 --> 00:00:12.620 Sjors, make the pun. 00:00:12.880 --> 00:00:14.240 We have a lot to talk about. 00:00:14.480 --> 00:00:16.400 We have a lot to discuss. 00:00:17.020 --> 00:00:17.580 Yes. 00:00:18.150 --> 00:00:23.330 In this episode, we're going to discuss the Taproot activation process and the 00:00:23.330 --> 00:00:28.830 debate surrounding it on the parameter LOT. Lock in on timeout. 00:00:29.330 --> 00:00:29.970 That's right. 00:00:30.110 --> 00:00:32.190 Which can be set to true and false. 00:00:32.410 --> 00:00:36.130 And maybe as a reminder to the listener, we have talked about Taproot in general 00:00:36.130 --> 00:00:40.970 multiple times, but especially in episode two. And we've talked about activating 00:00:40.970 --> 00:00:46.030 Taproot, activating soft forks in general in episode three. So we might skip over 00:00:46.030 --> 00:00:46.590 a few things. 00:00:47.070 --> 00:00:51.910 Yeah, in episode three, we discussed all sorts of different proposals to activate 00:00:51.910 --> 00:00:55.850 Taproot, but it's been over half a year at least right? 00:00:55.850 --> 00:00:58.990 That was on September 25th, so about five months, yeah. 00:00:58.990 --> 00:01:04.030 Yeah so it's been a while, and by now the discussion has reached sort of its 00:01:04.030 --> 00:01:09.050 final stage, I would say. And at this point the discussion is about the LOT 00:01:09.050 --> 00:01:14.930 parameter true or false. First, to recap very briefly, Sjors, can you explain 00:01:14.930 --> 00:01:17.630 what are we doing here? What is the soft fork? 00:01:18.510 --> 00:01:23.350 Right. So the idea of a soft fork is that you make the rules more strict. And 00:01:23.350 --> 00:01:27.870 that means that from the point of view of a node that doesn't upgrade, nothing 00:01:27.870 --> 00:01:31.850 has changed. They're just seeing transactions that are valid to them. From the 00:01:31.850 --> 00:01:35.290 nodes that do upgrade, because they have more stricter rules, they do care what 00:01:35.290 --> 00:01:38.930 happens. But the nice thing about soft forks is that as a node user, you can 00:01:38.930 --> 00:01:42.210 upgrade whenever you want. If you don't care about this feature, you can upgrade 00:01:42.210 --> 00:01:42.750 whenever you want. 00:01:43.330 --> 00:01:49.290 Yeah, soft fork is a backwards compatible protocol upgrade. And the nice thing 00:01:49.290 --> 00:01:53.990 about it is that if at least half of all miners, if a majority of miners enforces 00:01:53.990 --> 00:01:58.770 the rules, then that sort of automatically means all nodes on the network will 00:01:58.770 --> 00:02:00.010 follow the same blockchain. 00:02:00.370 --> 00:02:03.490 That's right, because the older nodes don't know about these new rules, but they 00:02:03.490 --> 00:02:07.370 do know that they'll follow the chain with the most proof of work as long as it's 00:02:07.370 --> 00:02:12.180 valid. And so if most of the miners are following the new rules, then most of the 00:02:12.180 --> 00:02:16.760 proof of work will be following the new rules. And so a node will, by definition, 00:02:16.960 --> 00:02:17.360 follow that. 00:02:18.770 --> 00:02:20.870 An old node will, by definition, follow it. 00:02:22.070 --> 00:02:27.030 Okay, so the nice thing about soft forks is that if a majority of hash power 00:02:27.030 --> 00:02:32.680 enforces the new rules, the network will remain in consensus. Therefore, 00:02:33.140 --> 00:02:37.920 the last couple of soft forks were activated through hash power coordination. 00:02:38.950 --> 00:02:44.490 That means that miners could include a bit in the blocks they mined, 00:02:44.570 --> 00:02:49.770 signaling that they were ready for the upgrade. And once most miners, it was 00:02:49.770 --> 00:02:54.930 95% in most cases, 95% of miners indicated that they were ready, 00:02:56.200 --> 00:02:59.140 nodes would recognize this and enforce the upgrade. 00:02:59.580 --> 00:03:00.560 Yeah, that's right. 00:03:01.420 --> 00:03:01.860 Okay. 00:03:02.140 --> 00:03:07.100 And so this would involve a node would check, for example, every two weeks, how 00:03:07.100 --> 00:03:11.920 many blocks signaled this thing, and if yes, then it says okay, the soft fork is 00:03:11.920 --> 00:03:14.360 now active. I'm going to assume that the miners will enforce this. 00:03:14.360 --> 00:03:20.360 Right. Now the problem with this upgrade mechanism is that it 00:03:20.360 --> 00:03:22.960 also means miners can block the upgrades. 00:03:23.380 --> 00:03:24.400 Yeah, that's the downside. 00:03:24.700 --> 00:03:29.160 Even if everyone agrees with the upgrade, so for example, in this case, Taproot, 00:03:29.280 --> 00:03:35.080 it seems to have broad consensus. But despite that broad consensus, miners 00:03:35.080 --> 00:03:39.600 could still block the upgrade, which is what happened with SegWit a couple of 00:03:39.600 --> 00:03:40.000 years ago. 00:03:40.480 --> 00:03:44.960 Right, back then there was a lot of debate about the block size and lots of hard 00:03:44.960 --> 00:03:50.260 fork proposals and lots of hurt feelings. And so... Now, eventually 00:03:50.260 --> 00:03:55.020 it was very difficult to get SegWit activated because miners were not signaling 00:03:55.020 --> 00:04:00.680 for it, probably mostly intentionally. Now, it could also happen that miners just 00:04:00.680 --> 00:04:04.420 ignore an update, not because they don't like it, just because they're busy. 00:04:04.760 --> 00:04:10.710 Yeah, in the case of SegWit, that was, in the end, resolved through 00:04:10.710 --> 00:04:14.890 UASF or at least that was part of it, we're not going to get into that in depth 00:04:14.890 --> 00:04:20.870 right but that basically meant that a group of users said on this day 00:04:20.870 --> 00:04:26.710 some date in the future, was August 1st 2017, we're going to activate the 00:04:26.710 --> 00:04:30.610 SegWit rules no matter how much hash power actually supports it. 00:04:31.030 --> 00:04:35.290 Right, and at the same time, and perhaps as a consequence of that, a group of 00:04:35.290 --> 00:04:40.110 miners and other companies agreed that they would start signaling for SegWit, and 00:04:40.110 --> 00:04:43.590 there was a whole bunch of other things going on at the same time. But whatever 00:04:43.590 --> 00:04:47.270 happened on the 1st of August, the thing activated, or a little bit earlier, I think. 00:04:47.610 --> 00:04:52.430 Yeah, okay, so now we're four years ahead in time. It's four years later, and now 00:04:52.430 --> 00:04:58.010 the Taproot upgrade is ready to go. And what happened a couple years ago is 00:04:58.010 --> 00:05:03.720 now spurring new debate on the Taproot upgrade. And that brings us to the LOT 00:05:03.720 --> 00:05:09.460 parameter, which is a new parameter. Although, you know, it's sort of inspired 00:05:09.460 --> 00:05:12.920 by things from that SegWit upgrade period. 00:05:13.100 --> 00:05:18.620 It's basically like a built-in UASF option, which 00:05:18.620 --> 00:05:24.610 you can decide to use or not. But it's basically, there is now a sort of a 00:05:24.610 --> 00:05:29.960 formal way in the protocol to do this, to activate a soft fork like at a cutoff date. 00:05:29.960 --> 00:05:35.880 Yeah, so LOT has two options. The first option is false. So that LOT is 00:05:35.880 --> 00:05:41.660 false. That means that miners can signal for the upgrade for one year 00:05:41.660 --> 00:05:47.000 and then in that year if there's 90 thresholds for the upgrade it will 00:05:47.000 --> 00:05:52.920 activate, as we just explained. By the way, one year and 90 isn't set in 00:05:52.920 --> 00:05:57.340 stone, but that's sort of what people seem to settle on. For convenience sake, 00:05:57.460 --> 00:06:01.240 that's just what I'm going to use while discussing this. So miners have one year 00:06:01.240 --> 00:06:07.180 to activate the upgrade. If after that year they have not upgraded, the Taproot 00:06:07.180 --> 00:06:11.280 upgrade will expire. It will just not happen, basically. That LOT is false. 00:06:11.540 --> 00:06:14.360 And of course, there's always the option then of shipping any release, trying 00:06:14.360 --> 00:06:18.520 again. It's not that… it's… it's not a no vote but it just nothing happens. 00:06:19.080 --> 00:06:23.060 Yeah, exactly. Okay, then there's LOT is true, 00:06:24.000 --> 00:06:29.670 which... Again, miners have one year to signal support for the upgrade. 00:06:29.930 --> 00:06:35.710 If a 90% threshold is met, then the upgrade will activate. However, 00:06:36.010 --> 00:06:41.860 the big difference is what happens if miners don't reach this threshold if 00:06:41.860 --> 00:06:46.940 they don't signal for the upgrade. In that case, when the year is almost over, 00:06:47.500 --> 00:06:53.380 nodes that have LOT is true will start to reject all blocks that don't 00:06:53.380 --> 00:06:59.100 signal for the upgrade. In other words, they only accept blocks that will signal 00:06:59.100 --> 00:07:04.820 for the upgrade, which means, of course, that the 90% threshold will be met 00:07:04.820 --> 00:07:10.240 and therefore Taproot, or any other soft fork in this mechanism, 00:07:10.500 --> 00:07:12.040 will activate. 00:07:12.930 --> 00:07:14.610 If enough blocks are produced. 00:07:14.850 --> 00:07:19.250 If enough blocks are produced, yes, that's… that's true. A little bit of nuance 00:07:19.250 --> 00:07:25.030 is that, for those who find that interesting, even LOT is true nodes will accept 00:07:25.030 --> 00:07:27.710 up to 10% of blocks that don't signal. 00:07:29.200 --> 00:07:31.960 That's to avoid weird chain split scenarios? 00:07:32.300 --> 00:07:37.500 Yeah, basically because if it activates in a normal way, only 90% has a signal. 00:07:37.740 --> 00:07:41.900 So if you mandate signaling, then it would be weird to have a different 00:07:41.900 --> 00:07:42.700 percentage suddenly. 00:07:43.060 --> 00:07:47.320 Yeah, so they're going to accept the first 10% of non-signaling blocks, but after 00:07:47.320 --> 00:07:51.560 that, every block that doesn't signal is going to be rejected. So the 90% 00:07:51.560 --> 00:07:56.440 threshold will definitely be reached. Now, the big reason for 00:07:56.440 --> 00:08:02.220 LOT is true, for that parameter to set it to true, is that this way 00:08:02.220 --> 00:08:07.310 miners cannot block the upgrade. Even if they try to block the upgrade, 00:08:07.690 --> 00:08:13.970 once the year is over, nodes will still enforce Taproot. So it's guaranteed to happen. 00:08:14.720 --> 00:08:16.140 If enough blocks are produced. 00:08:16.340 --> 00:08:17.680 If enough blocks are produced. 00:08:17.900 --> 00:08:21.980 Yeah, we can get into some of the risks with this, but I think you want to 00:08:21.980 --> 00:08:23.060 continue explaining a bit. 00:08:23.280 --> 00:08:28.800 Yeah, so in other words, the reason some people like LOT is true, it's because 00:08:28.800 --> 00:08:31.610 that way miners don't have a veto, a veto. 00:08:33.050 --> 00:08:38.950 Now the counter argument there, and you already sort of suggested that, is 00:08:38.950 --> 00:08:44.450 that miners don't have a veto anyways. Even if we use LOT is false, 00:08:45.350 --> 00:08:51.210 the upgrade would expire after a year. But after that year, we can 00:08:51.210 --> 00:08:56.770 just deploy a new upgrade mechanism and a new signaling period. 00:08:57.050 --> 00:08:58.830 And this time maybe use LOT is true. 00:08:59.310 --> 00:09:04.410 Yes, or even while this thing is going on, right? So you could wait half a year 00:09:04.410 --> 00:09:09.090 with the LOT is false. And then half a year later saying, okay, this is taking 00:09:09.090 --> 00:09:13.070 too long. Let's take a little bit more risk and set LOT to true. 00:09:13.290 --> 00:09:13.790 Exactly. 00:09:14.130 --> 00:09:15.390 Or lower the threshold. 00:09:15.810 --> 00:09:16.050 Yes. 00:09:16.270 --> 00:09:19.710 Or some other permutation that slightly increases the risk, but also increases 00:09:19.710 --> 00:09:20.930 the likeness of activation. 00:09:21.410 --> 00:09:27.150 Yeah, you're right. But that's actually also one of the arguments against using 00:09:27.220 --> 00:09:32.680 LOT is false. LOT is true proponents say that because 00:09:32.680 --> 00:09:37.360 you just suggested we can do it after six months but there's another group of 00:09:37.360 --> 00:09:41.740 users that might say no no first wait until the year is over and then we'll just 00:09:41.740 --> 00:09:47.320 redeploy again. So let's say that after six months Taproot hasn't activated 00:09:47.320 --> 00:09:52.060 now all of a sudden you get a new discussion between people that want to 00:09:53.370 --> 00:09:57.730 start deploying LOT is true clients right away and groups of users that want to 00:09:57.730 --> 00:10:01.770 wait until the year is over. So it's sort of reintroducing the discussion we're 00:10:01.770 --> 00:10:06.370 having now, except by then we only have six months to resolve it. It's like a 00:10:06.370 --> 00:10:07.950 ticking time bomb kind of situation. 00:10:08.780 --> 00:10:12.720 Well, not really to resolve it. I mean, if you don't do anything for six months, 00:10:12.840 --> 00:10:15.820 then there's only one option left, which is to just try again with the new 00:10:15.820 --> 00:10:16.800 activation bit. 00:10:17.850 --> 00:10:20.930 Yeah, but then you need to agree on when you're actually going to do that. Are 00:10:20.930 --> 00:10:23.690 you going to do that after six months or are you going to do that later? And 00:10:23.690 --> 00:10:24.510 people might disagree. 00:10:26.050 --> 00:10:30.250 Yeah, then you'd be back to where we are now, except you know a little bit more 00:10:30.250 --> 00:10:32.070 because now you know that the miners weren't signaling. 00:10:32.430 --> 00:10:37.150 Yeah, and you don't have a lot of time to resolve it because after six months, 00:10:37.250 --> 00:10:41.500 something might happen. Some group of users might run through. 00:10:42.100 --> 00:10:47.260 Yeah, so the thing you're talking about here is the possibility of, say, anarchy 00:10:47.260 --> 00:10:52.060 in the sense that there's no consensus about when to activate this thing. And one 00:10:52.060 --> 00:10:55.860 group, I think we discussed this at length in the third episode, one group just 00:10:55.860 --> 00:10:59.960 gets really aggressive and says, no, we're going to activate this earlier. And so 00:10:59.960 --> 00:11:02.580 then nobody knows when it's going to happen. 00:11:04.460 --> 00:11:09.240 Yes, well, and also let me put it differently. If right now we're saying, okay, 00:11:09.420 --> 00:11:13.820 if after six months miners haven't activated for 00:11:14.400 --> 00:11:20.220 Taproot, then we'll just upgrade to LOT is true clients after six months. 00:11:21.280 --> 00:11:25.260 Then LOT is true proponents will say, well, if that's the plan anyways, let's 00:11:25.260 --> 00:11:30.800 just do it now. That's much easier. Why do we have to do that halfway? So that's 00:11:30.800 --> 00:11:32.640 sort of the counter argument to the counter argument. 00:11:33.280 --> 00:11:37.380 Yeah, I can see that. But of course, there's also the scenario where we never do 00:11:37.380 --> 00:11:43.360 this, where Taproot just doesn't activate. I mean, it just depends on what people 00:11:43.360 --> 00:11:47.820 want. But there is something to be said for a status quo bias where you don't do 00:11:47.820 --> 00:11:51.220 anything if it's too controversial for whatever reason. Now, there's another sort 00:11:51.220 --> 00:11:57.130 of a side case here that is useful to keep in mind. There might 00:11:57.130 --> 00:12:02.870 be a very good reason to cancel Taproot, right? There might just be a bug that... 00:12:02.870 --> 00:12:05.890 You're getting ahead of me, Sjors, You're getting ahead of me… Let me… Because 00:12:05.890 --> 00:12:08.730 there are a bunch of arguments in favor of LOT is false. 00:12:09.030 --> 00:12:09.310 Okay. 00:12:09.510 --> 00:12:13.900 Okay, so one argument is we've basically already done LOT 00:12:13.900 --> 00:12:19.490 is false a bunch of times, the previous miner activated soft forks. 00:12:19.750 --> 00:12:24.070 And most of the times it went fine. There was just this one time with SegWit in 00:12:24.070 --> 00:12:29.190 the midst of a big war. And we don't have a big war now. There's no reason to 00:12:29.190 --> 00:12:34.610 change what we've been doing successfully until now. That's one argument. The 00:12:34.610 --> 00:12:38.470 counter argument would, for example, be, yeah, but if you choose LOT is false 00:12:38.470 --> 00:12:44.190 now, that could actually draw controversy itself. You know, that could be 00:12:44.190 --> 00:12:48.510 used to drive a wedge or, you know, we're not in a war right now, but it could 00:12:48.510 --> 00:12:49.190 cause a war. 00:12:49.770 --> 00:12:52.490 Yeah, but I don't see how that argument doesn't apply to LOT is true. 00:12:52.970 --> 00:12:57.770 No, that's probably fair. Yeah, I tend to agree with that. 00:12:58.630 --> 00:13:03.590 Okay, then the other argument for LOT is false is that miners and especially 00:13:03.590 --> 00:13:08.790 mining pools have already indicated that they're supportive of Taproot and that 00:13:08.790 --> 00:13:14.390 I'll activate it and you know it's not necessary to do the LOT is true thing 00:13:14.390 --> 00:13:19.650 as far as we can tell. Then the third argument is what you just mentioned 00:13:19.650 --> 00:13:25.470 is that it's possible that maybe someone finds a bug with Taproot, 00:13:25.470 --> 00:13:31.270 maybe a software bug or maybe some other problem is possible and then if you do 00:13:31.270 --> 00:13:37.130 LOT is false it's fairly easy to just let it expire and users won't have to 00:13:37.130 --> 00:13:38.330 upgrade their software again. 00:13:38.610 --> 00:13:42.190 Right, the only thing then you'd have to recommend that miners do not install 00:13:42.190 --> 00:13:46.490 that upgrade. And it's worth noting, I think we pointed this out in episode 00:13:46.490 --> 00:13:51.690 three, people don't always review things very early. So it's very possible that a 00:13:51.690 --> 00:13:55.550 lot of you know a lot of people have reviewed Taproot code, but others might not 00:13:55.550 --> 00:13:59.870 bother to review it until the activation code is there because they just wait for 00:13:59.870 --> 00:14:04.470 the last minute. So it's… it's not implausible that somebody, you know, very 00:14:04.470 --> 00:14:08.870 smart starts reviewing this very late. Perhaps some exchange that's, you know, 00:14:08.950 --> 00:14:09.650 about to deploy it. 00:14:09.830 --> 00:14:15.810 Yeah, something like that happened with the P2SH. So the predecessor to P2SH was 00:14:15.810 --> 00:14:21.500 OP_CSV, I think. That was just about to be deployed and then a 00:14:21.500 --> 00:14:23.020 pretty horrible bug was found. 00:14:23.220 --> 00:14:27.420 Yeah, we've seen it with certain altcoins too, that right before deployment, 00:14:27.440 --> 00:14:30.700 people find zero days, either because they're bullies or just because the code 00:14:30.700 --> 00:14:34.820 was shipped in a rush and nobody checked it. So there is definitely always a 00:14:34.820 --> 00:14:38.540 risk, whatever soft fork mechanism you use, that a bug is discovered at the last 00:14:38.540 --> 00:14:41.980 minute. And if you're really unlucky, then it's too late, it's deployed, and you 00:14:41.980 --> 00:14:44.900 need a hard fork to get rid of it, which would be really, really bad. 00:14:45.410 --> 00:14:48.950 Well, no, I don't think that's true. There are other ways to get rid of it. 00:14:49.230 --> 00:14:52.730 Oh yeah, you may be able to soft fork, depending on what the bug is, you may be 00:14:52.730 --> 00:14:54.190 able to soft fork it out. Yeah, 00:14:54.910 --> 00:14:59.850 There are ways to fix it even in that case. And the other sort of counter 00:14:59.850 --> 00:15:04.870 argument to that point would be, well, if we're not sure that 00:15:04.870 --> 00:15:08.650 it's bug free and if we're not sure that this upgrade is correct and it shouldn't 00:15:08.650 --> 00:15:12.910 be deployed. Either way, not in false or true or anything. So we need to be sure 00:15:12.910 --> 00:15:13.570 of that anyways. 00:15:13.970 --> 00:15:18.330 Yeah, but like I said, some people won't review something until it is sort of 00:15:18.330 --> 00:15:18.790 inevitable. 00:15:19.730 --> 00:15:22.490 Yeah, I'm just… I'm just listing the arguments. 00:15:22.730 --> 00:15:23.090 That's all right. 00:15:24.210 --> 00:15:29.810 Okay, fourth argument. So the fourth argument for LOT is false, basically, or 00:15:29.810 --> 00:15:34.750 against LOT is true, is that LOT is true. Am I saying that right? Against LOT is 00:15:34.750 --> 00:15:39.770 true? Yeah. LOT is true could feed into the perception that Bitcoin and 00:15:39.770 --> 00:15:44.810 especially Bitcoin Core developers control the protocol have power over the 00:15:44.810 --> 00:15:49.470 protocol because you know they're shipping code and that becomes that sort of 00:15:49.470 --> 00:15:53.450 necessarily becomes the new protocol rules in the case of in the case of Taproot 00:15:53.450 --> 00:15:55.630 so that perception could… 00:15:56.250 --> 00:16:00.450 There could be some future soft fork where really nobody in the community cares 00:16:00.450 --> 00:16:05.490 about it, but just a handful of Bitcoin Core developers do, and they kind of 00:16:05.490 --> 00:16:11.190 force it onto the community, and then you get a bunch of chaos. The… the nice 00:16:11.190 --> 00:16:13.790 thing about having at least a miner signal is that they are part of the 00:16:13.790 --> 00:16:17.710 community, and at least they are okay with it. But the problem is it doesn't 00:16:17.710 --> 00:16:20.970 reflect… it doesn't reflect what other people in the community think about it. It 00:16:20.970 --> 00:16:23.910 just reflects what they think about it. So there's a bunch of mechanisms, right? 00:16:24.010 --> 00:16:27.770 There's a discussion on the mailing list. And you see if people have problems, 00:16:27.990 --> 00:16:31.910 then there's the miner signaling, which is a nice indication that people are 00:16:31.910 --> 00:16:37.300 happy. So you could just see it as that, as many people consenting as possible. 00:16:37.660 --> 00:16:39.960 It'd be nice if there were other mechanisms, of course. 00:16:40.240 --> 00:16:44.860 Yeah, the other point is that, you know, Bitcoin Core developers, while they 00:16:44.860 --> 00:16:48.840 decide which software they include in Bitcoin Core, which code they include in 00:16:48.840 --> 00:16:52.460 Bitcoin Core, they don't decide what users actually end up running. 00:16:52.800 --> 00:16:55.300 No, exactly. So nobody might download it. 00:16:55.870 --> 00:17:00.170 Yeah, exactly. They don't actually have power over the network. So in that sense, 00:17:00.370 --> 00:17:05.840 the argument is bunk, but it could still feed into the perception that 00:17:05.840 --> 00:17:10.180 they do. And even that perception, if you can avoid it, maybe that's better. 00:17:10.360 --> 00:17:11.080 That's sort of an argument. 00:17:11.160 --> 00:17:16.280 And the precedent, right? But if Bitcoin Core is compromised at some point and 00:17:16.280 --> 00:17:20.100 ships an update and says, well, if you don't stop it, then it's going to 00:17:20.100 --> 00:17:23.930 activate. And then it's actually nice if the miners can say, nah, I don't think so. 00:17:24.310 --> 00:17:30.170 But users could say that as well by not downloading it, like you said. Okay, then 00:17:30.170 --> 00:17:35.790 now we get to the fifth argument. And this is the most, this is where it gets 00:17:35.790 --> 00:17:41.350 pretty complex. Okay, so the fifth argument against LOT is true 00:17:41.350 --> 00:17:46.250 is that it could cause all sorts of network instability. 00:17:47.580 --> 00:17:53.580 If it happens that the year is over and there are LOT is true clients 00:17:53.580 --> 00:17:59.060 on the network, it's possible that they would split off from the main chain 00:17:59.060 --> 00:18:04.760 and there could be reorgs and people could lose money and miners 00:18:04.760 --> 00:18:09.780 could mine invalid block and lose their block rewards and all that sort of stuff. 00:18:11.000 --> 00:18:16.660 But the LOT is true proponents argue that that risk is 00:18:16.660 --> 00:18:20.380 actually best mitigated if people adopt a LOT is true. 00:18:20.960 --> 00:18:25.600 Yeah I'm very skeptical that sounds very circular but maybe it's useful to 00:18:25.600 --> 00:18:27.880 explain what these bad scenarios look like. 00:18:27.880 --> 00:18:29.620 That's exactly where I wanted to get at. 00:18:29.620 --> 00:18:33.520 Yeah, and then others can decide whether a they think those bad scenarios are 00:18:33.520 --> 00:18:37.780 worth risking and b whether they think you know how to make them less likely 00:18:38.190 --> 00:18:42.250 because some of that I think is almost political. It's kind of like, you know, 00:18:42.330 --> 00:18:45.530 you have all these discussions in society, like should people have guns or not? 00:18:45.690 --> 00:18:50.530 And, you know, what's the incentives? And you may never figure that out. But we 00:18:50.530 --> 00:18:52.150 can talk about some of the mechanics here. 00:18:52.270 --> 00:18:57.910 Just to be clear, if somehow there would be complete consensus on the 00:18:57.910 --> 00:19:03.060 network over either LOT is true, all nodes run LOT is true, 00:19:03.280 --> 00:19:09.260 or all nodes run LOT is false, then I think that would be totally fine 00:19:09.260 --> 00:19:10.160 either way. 00:19:10.480 --> 00:19:13.560 Yeah, but the irony, of course, is that if there's complete consensus and 00:19:13.560 --> 00:19:17.240 everybody runs LOT is true, then it will never be used. But you're right in theory. 00:19:17.720 --> 00:19:21.360 Well, I mean, even if miners wouldn't... 00:19:20.640 --> 00:19:24.960 I don't… I don't see a scenario where miners would say, yeah, we're happy with 00:19:24.960 --> 00:19:29.020 LOT is true. We're just not deliberately not going to signal and then signal at 00:19:29.020 --> 00:19:29.860 the very last moment. 00:19:30.580 --> 00:19:36.430 Yeah, you're right. But we're also digressing. The point is that... the really 00:19:36.430 --> 00:19:42.050 complicated scenarios arise when some parts of the network are running LOT is 00:19:42.050 --> 00:19:48.030 true, some parts of the network are running LOT is false, or some parts of the 00:19:48.030 --> 00:19:52.510 network are running neither because they haven't upgraded, or some combination of 00:19:52.510 --> 00:19:56.310 these, you know, half of the network is true, half of the network is neither. 00:19:56.670 --> 00:20:02.590 That's where things get very complicated, and Sjors, you've thought about it. 00:20:03.170 --> 00:20:03.930 What do you think? 00:20:04.350 --> 00:20:10.250 The nice thing is, I kind of thought about this stuff during the SegWit2x debacle 00:20:10.250 --> 00:20:14.670 as well as the UASF debacle, which were similar in a way, but also very different 00:20:14.670 --> 00:20:17.710 because of who was doing this [unclear] and whether it was a hard fork or a soft 00:20:17.710 --> 00:20:23.460 fork. But, okay, so let's say you are running the current version of Bitcoin 00:20:23.460 --> 00:20:27.660 Core. Now, let's start easier. Okay, let's say you're running the LOT is true 00:20:27.660 --> 00:20:30.980 version of Bitcoin Core. You downloaded it, and maybe it was released by Bitcoin 00:20:30.980 --> 00:20:35.220 Core, maybe you self-compiled it, but it says LOT is true. You want Taproot to 00:20:35.220 --> 00:20:40.000 activate. But the scenario here we're taking is that the rest of the world, the 00:20:40.000 --> 00:20:45.860 miners aren't really doing this. And the day arrives, and you see 00:20:45.860 --> 00:20:50.330 a block, and it's not signaling correctly. But you want it to signal correctly. 00:20:50.510 --> 00:20:54.650 So you say, this block is now invalid. I'm not going to accept this block. And 00:20:54.650 --> 00:20:58.450 I'm just going to wait until another miner comes with a block that does meet my 00:20:58.450 --> 00:21:04.130 criteria. And maybe that happens once in every 10 blocks, for example. So you are 00:21:04.130 --> 00:21:08.550 seeing new blocks, but they're coming in very, very slowly. Okay, so somebody 00:21:08.550 --> 00:21:13.230 sends you a transaction. You know, you won Bitcoin from somebody, they sent you a 00:21:13.230 --> 00:21:19.210 transaction. And this transaction has a fee, and it's probably going to 00:21:19.210 --> 00:21:23.610 be wrong. So let's say you're receiving a transaction from somebody who is 00:21:23.610 --> 00:21:28.650 running a node with LOT is false. So they're on a chain that is going 10 times 00:21:28.650 --> 00:21:34.410 faster than you are, right? This is intermediate state. Their blocks might be 00:21:34.410 --> 00:21:40.340 just full, so their fees are pretty low, and you're receiving it. But 00:21:40.340 --> 00:21:45.580 you're on this shorter, slower moving chain. So your mempool is really full and 00:21:45.580 --> 00:21:49.360 your blocks are completely full. So that transaction probably won't confirm on 00:21:49.360 --> 00:21:52.240 your side. It's just going to be sitting in the mempool. That's just one 00:21:52.240 --> 00:21:55.880 complexity. And that's actually a relatively good scenario because you don't 00:21:55.880 --> 00:21:57.520 accept unconfirmed transactions. 00:21:57.900 --> 00:21:58.280 Yeah. 00:21:58.440 --> 00:22:01.420 So you'll have a disagreement with your counterparty. You'll say, okay, it hasn't 00:22:01.420 --> 00:22:05.460 confirmed. And they'll say it has confirmed. Then at least you might realize 00:22:05.460 --> 00:22:10.620 what's going on. You know, you read about the LOT war or whatever. So that's one 00:22:10.620 --> 00:22:14.460 scenario. The other scenario is where somehow it does confirm on your side, but 00:22:14.460 --> 00:22:20.100 maybe it also confirms on the other side. So that's kind of good because 00:22:20.350 --> 00:22:24.270 then you're safe either way, right? If it's confirmed on both sides and whatever 00:22:24.270 --> 00:22:29.090 happens in a future reorg, that transaction is actually on the chain, just maybe 00:22:29.090 --> 00:22:29.790 in a different block. 00:22:30.290 --> 00:22:30.750 Sure. 00:22:31.030 --> 00:22:35.030 Another scenario could be because these blocks are these chains, there's two 00:22:35.030 --> 00:22:38.950 chains, one short chain, one long chain, but they're different. And so if you're 00:22:38.950 --> 00:22:43.270 receiving coins that are from the coinbase, that descend from a coinbase 00:22:43.270 --> 00:22:48.130 transaction on one side or the other, then there's no way it can be valid on your side. 00:22:48.590 --> 00:22:48.710 Yeah. 00:22:49.150 --> 00:22:54.370 And this can also be a feature. It's called replay protection, essentially. So 00:22:54.370 --> 00:22:58.930 you receive a transaction and you just don't even see it in your mempool and you 00:22:58.930 --> 00:23:03.190 call the other person and you say, this doesn't make any sense. So that's good. 00:23:03.730 --> 00:23:09.670 Okay. But now, suddenly, the world changes its mind and 00:23:09.670 --> 00:23:13.850 says, no, we do want Taproot, we do want LOT is true, we are now LOT is true 00:23:13.850 --> 00:23:18.950 diehards. And all the miners start mining on top of your shorter chain and your 00:23:18.950 --> 00:23:23.690 short chain becomes the very long chain. So in that case, you're pretty happy in 00:23:23.690 --> 00:23:26.390 most of the scenarios we discussed, right? The transaction… 00:23:26.390 --> 00:23:27.010 Sounds good to me. 00:23:27.250 --> 00:23:30.990 Right, you had a transaction that was in maybe your 10th block and on the other 00:23:30.990 --> 00:23:34.370 side it was in the first block, but it's still yours. There were some 00:23:34.370 --> 00:23:38.730 transactions floating in the mempool for a very long time that finally confirmed. 00:23:39.690 --> 00:23:45.050 I think you're… you're fairly happy, but I wonder if I was doing it right. Yeah, 00:23:45.130 --> 00:23:47.910 so we were talking about the LOT is true node, right? So… so yeah, as a 00:23:47.910 --> 00:23:51.940 LOT is true node user… It sounds like in these scenarios, you're happy. 00:23:52.480 --> 00:23:52.880 Yep. 00:23:53.100 --> 00:23:55.420 Maybe not if you're paying someone, but anyway. 00:23:55.920 --> 00:23:59.980 You're starting to make the case for LOT is true Sjors, I know that's not your 00:23:59.980 --> 00:24:02.400 intention, but you're doing a good job at it. 00:24:02.540 --> 00:24:06.140 For the full-node user who knows what they're doing in general, right? If you're 00:24:06.140 --> 00:24:09.520 a full-node user and you know what you're doing, then I think you're going to be 00:24:09.520 --> 00:24:13.980 fine in general. I think, yeah, this is not too bad. Now, let's say you are a 00:24:13.980 --> 00:24:19.180 LOT is false user, and let's say you… 00:24:19.730 --> 00:24:22.470 You just are, you know, you don't know what you're doing or you do know what 00:24:22.470 --> 00:24:26.670 you're doing. I don't know. Pick one. In the same scenario, you're on the longest 00:24:26.670 --> 00:24:31.790 chain. You're receiving coins from an exchange. And you've seen these headers out 00:24:31.790 --> 00:24:36.460 there for this shorter chain. You might have seen them. Depends on whether they 00:24:36.460 --> 00:24:40.580 reach you or not. But it's a shorter chain. And it's valid according to you 00:24:40.580 --> 00:24:45.680 because it's a more strict rule set. So you're fine. So this other chain has 00:24:45.680 --> 00:24:50.620 Taproot and you don't probably. And you're accepting transactions and you're a 00:24:50.620 --> 00:24:55.080 happy camper. But then all of a sudden, because the world changes, everything 00:24:55.080 --> 00:24:58.580 disappears from under you. All the transactions you've seen confirmed in the 00:24:58.580 --> 00:25:02.520 block are now back in the mempool. And it might have been double spent even. 00:25:02.740 --> 00:25:08.670 Yeah, the reason for that is that even if you're running LOT is 00:25:08.670 --> 00:25:13.500 false, if the LOT is true chain, we're talking about the chain split that's 00:25:13.500 --> 00:25:19.380 happened… So if your LOT is false node… but at some point at any point the 00:25:19.380 --> 00:25:24.660 LOT is true chain becomes the longest chain then your LOT is false node would 00:25:24.660 --> 00:25:29.260 still accept that chain it would still consider it valid. Yeah, the other way 00:25:29.260 --> 00:25:33.350 around is not true. But the LOT is false node will always consider the LOT is 00:25:33.350 --> 00:25:39.150 true chain valid. So in your scenario, we're using Bitcoin on the 00:25:39.150 --> 00:25:43.750 longest chain, on the LOT is false chain. We're happy. We receive money. You 00:25:43.750 --> 00:25:47.010 know, we did a hard days of work and we got our paycheck at the end. 00:25:47.170 --> 00:25:47.290 Yeah. 00:25:48.360 --> 00:25:52.680 Paid in Bitcoin. We think we're safe. We got a bunch of confirmations. But then 00:25:52.680 --> 00:25:57.470 all of a sudden, the LOT is true chain becomes longer. Which means your node 00:25:57.470 --> 00:26:01.350 switches to the LOT is true chain and that money you received on the LOT is false 00:26:01.350 --> 00:26:04.950 chain, which you thought was the Bitcoin chain, is just gone. Poof. 00:26:05.310 --> 00:26:05.790 Right. 00:26:06.210 --> 00:26:07.670 That's the problem you're talking about. 00:26:08.090 --> 00:26:10.410 Exactly. Now you could still say, okay. 00:26:10.320 --> 00:26:15.110 I will… I will add to this very briefly. I think this is an even bigger problem 00:26:15.110 --> 00:26:17.510 for non-upgraded nodes. 00:26:18.030 --> 00:26:19.370 Yeah, I was about to get to that. 00:26:19.530 --> 00:26:19.730 Okay. 00:26:20.130 --> 00:26:23.010 So, right. So now we're talking about the LOT is false people and you could still 00:26:23.010 --> 00:26:26.870 say, well, why did you download the LOT is false version? Well, because you 00:26:26.870 --> 00:26:32.160 didn't know. Okay. Now we're talking about an unupgraded node. Now, for the 00:26:32.160 --> 00:26:36.920 unupgraded node, Taproot does not exist. So it has no preference for which of the 00:26:36.920 --> 00:26:38.380 chains. It will just pick the longest one. 00:26:39.120 --> 00:26:43.360 Yeah, it's someone in Korea. He doesn't keep up with discussion. 00:26:43.740 --> 00:26:44.660 Well, let's not be mean to Korea. 00:26:45.880 --> 00:26:48.520 No, well, pick a country where they don't speak English. 00:26:48.760 --> 00:26:49.980 North Korea, yeah. 00:26:51.190 --> 00:26:56.090 You know, someone doesn't keep up with their Bitcoin discussion forums, maybe 00:26:56.090 --> 00:26:59.990 doesn't read English, doesn't really care. He just likes the Bitcoin thing, 00:27:00.130 --> 00:27:03.610 downloaded the software a couple of years ago, now put in this hard days of work, 00:27:03.730 --> 00:27:05.090 gets paid, and the money disappears. 00:27:05.510 --> 00:27:09.850 Yeah, or his node might be in a nuclear bunker that he put it in five years ago 00:27:09.850 --> 00:27:12.850 under 15 meters of concrete, air-gapped. 00:27:13.580 --> 00:27:17.320 And he can… he can put… he can give it, you know, and somehow it can download 00:27:17.320 --> 00:27:20.560 blocks because it's watching the block stream satellite or something, but it 00:27:20.560 --> 00:27:21.400 cannot be upgraded. 00:27:22.620 --> 00:27:25.760 And he doesn't know about this upgrade, which would be odd if you're into nuclear 00:27:25.760 --> 00:27:26.600 bunkers and full nodes. 00:27:28.140 --> 00:27:31.680 Anyway, somebody is running an out of… an out-of-date node but but you know, in 00:27:31.680 --> 00:27:34.880