WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:09.780 --> 00:00:12.560 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:12.800 --> 00:00:12.980 Hello. 00:00:13.480 --> 00:00:13.960 Hey, Sjors. 00:00:14.140 --> 00:00:14.480 What's up? 00:00:15.340 --> 00:00:19.200 Sjors, today we have a lot more to discuss. 00:00:19.440 --> 00:00:20.760 Oh, we've already made this pun. 00:00:20.780 --> 00:00:22.480 We've already made it twice, I think. 00:00:22.660 --> 00:00:22.800 Yeah. 00:00:23.750 --> 00:00:29.210 It doesn't matter. We are going to discuss the final implementation details of 00:00:29.210 --> 00:00:30.650 Speedy Trial today. 00:00:30.760 --> 00:00:31.220 Yep. 00:00:31.240 --> 00:00:37.070 We've already covered Speedy Trial in a previous episode. This time we're also 00:00:37.070 --> 00:00:42.150 going to contrast it to the LOT=true client, which is an alternative that's been 00:00:42.150 --> 00:00:47.980 released by a couple of community members. And we're going to discuss how 00:00:47.980 --> 00:00:48.540 they compare. 00:00:49.080 --> 00:00:52.920 Yeah, that sounds like a good idea. And we also talked about Taproot activation 00:00:52.920 --> 00:00:55.620 options in general in a much earlier episode. 00:00:56.420 --> 00:00:57.640 One of the first ones? 00:00:57.960 --> 00:01:01.940 Yeah, where we also talked about this idea of this cowboy mentality where 00:01:01.940 --> 00:01:05.280 somebody would eventually release a LOT=true client, whatever you do. 00:01:07.040 --> 00:01:08.320 Yeah, so that's where we are. 00:01:08.480 --> 00:01:11.400 And we also, I think, predicted correctly that there would be a lot of bike shedding. 00:01:13.090 --> 00:01:17.900 Yes, which is also something we'll get into. So first of all, as a very brief 00:01:17.900 --> 00:01:20.860 recap. we're talking about Taproot activation. 00:01:21.220 --> 00:01:21.560 That's right. 00:01:22.040 --> 00:01:27.740 So Taproot is a proposed protocol upgrade 00:01:27.740 --> 00:01:33.480 for compact and potentially privacy-preserving smart contracts 00:01:33.480 --> 00:01:39.100 on the Bitcoin protocol. Is that a good summary in your opinion? 00:01:39.100 --> 00:01:40.040 Yeah, I think so. 00:01:40.760 --> 00:01:46.320 And the discussion on how to upgrade has been going on for a while now. The 00:01:46.320 --> 00:01:52.100 challenge is that on a decentralized open network 00:01:52.100 --> 00:01:58.100 like Bitcoin without a central dictator to tell everyone what to run when, 00:01:58.860 --> 00:02:04.520 you're not going to get everyone to upgrade at the same time. But we do want to 00:02:04.520 --> 00:02:07.860 keep the network in consensus somehow or another. 00:02:08.340 --> 00:02:11.630 Yeah, and there used to be... The other thing that can work when it's a 00:02:11.630 --> 00:02:16.150 distributed system is some sort of conventions that you're used to, you know, 00:02:16.230 --> 00:02:20.990 ways that you're used to doing things. But unfortunately, the convention we had 00:02:20.990 --> 00:02:25.530 kind of ran into problems with the SegWit deployment. So then the question is, 00:02:25.670 --> 00:02:29.290 okay, should we try something else or was it just a freak accident and should we 00:02:29.290 --> 00:02:30.630 just try the same thing again? 00:02:31.130 --> 00:02:33.830 Yeah, I think the last... 00:02:35.080 --> 00:02:40.500 preface before we really start getting into Speedy Trial is I'd like to point out 00:02:40.500 --> 00:02:46.040 the general idea with a soft fork, which is a backwards compatible upgrade, which 00:02:46.040 --> 00:02:52.020 Taproot is, means that if a majority of hash power is 00:02:52.020 --> 00:02:56.980 enforcing the new rules, that means the network will stay in consensus. 00:02:57.760 --> 00:02:58.240 Yeah. 00:02:58.870 --> 00:02:59.450 So. 00:02:59.730 --> 00:03:05.390 And also, I guess we can repeat that is that if you keep making 00:03:05.390 --> 00:03:09.510 transactions that are pre-Taproot then those transactions are still valid. 00:03:11.050 --> 00:03:15.630 So in that sense, you can, as a user, ignore soft forks. Unfortunately, if 00:03:15.630 --> 00:03:18.850 there's a problem, you cannot ignore that as a user, even if your transactions 00:03:18.850 --> 00:03:19.890 don't use that Taproot. 00:03:21.710 --> 00:03:27.470 Yeah. Well, so the general idea, I think everyone agrees that it is very nice 00:03:27.470 --> 00:03:30.150 if a majority of hash power enforces the rules. 00:03:30.430 --> 00:03:30.830 Yeah. 00:03:31.110 --> 00:03:36.390 And there are coordination mechanisms to sort of measure how many miners are on 00:03:36.390 --> 00:03:41.250 board with an upgrade. And that's how you can coordinate a fairly safe soft fork. 00:03:41.950 --> 00:03:42.090 Yeah. 00:03:42.810 --> 00:03:47.450 That's something everyone agrees on. And then there are parts where people start 00:03:47.450 --> 00:03:51.750 to disagree is what happens if miners don't actually cooperate with this 00:03:51.750 --> 00:03:56.450 coordination. We're not gonna rehash all of that. There's previous episodes about 00:03:56.450 --> 00:04:01.610 that. What we are gonna explain is that in the end the Bitcoin Core 00:04:01.610 --> 00:04:07.290 development community settled on a solution called Speedy Trial. 00:04:08.380 --> 00:04:13.420 Yes so and we already mentioned that as well in the previous episode but we're 00:04:13.420 --> 00:04:17.980 now now it's finalized basically and we're gonna explain what the finalized 00:04:17.980 --> 00:04:19.440 parameters are for this. 00:04:19.440 --> 00:04:20.840 Yeah and there was a slight change. 00:04:20.840 --> 00:04:26.600 So um let’s… let’s hear it Sjors, what are the finalized parameters for Speedy 00:04:26.600 --> 00:04:30.820 Trial? How are we… yeah so how is Bitcoin Core going to upgrade to Taproot? 00:04:30.820 --> 00:04:36.680 Yeah so for every um so starting on let's see I think it's this Sunday. 00:04:38.980 --> 00:04:40.280 April 24th, midnight. 00:04:40.680 --> 00:04:42.340 Yeah, I think that's this Sunday. 00:04:44.040 --> 00:04:49.820 Starting this Sunday, the first time the difficulty readjusts. So that happens 00:04:49.820 --> 00:04:52.420 every two weeks. So probably one week after next Sunday. 00:04:54.280 --> 00:04:55.240 Maybe it's Saturday. 00:04:55.720 --> 00:05:00.990 Yeah, the signaling starts. So in about two weeks, the signaling starts. No 00:05:00.990 --> 00:05:02.630 earlier than one week from now. 00:05:03.170 --> 00:05:04.070 Wait, just to be clear. 00:05:06.520 --> 00:05:08.660 That's the earliest it can start. 00:05:08.980 --> 00:05:12.380 The earliest it can start is April 24th. 00:05:12.520 --> 00:05:12.780 Yes. 00:05:13.220 --> 00:05:18.300 But because it only starts at a new difficulty adjustment period or a new 00:05:18.300 --> 00:05:21.860 retargeting period, it probably won't start until two weeks from now. 00:05:22.260 --> 00:05:28.030 Yeah, so it will start at the first new difficulty period after... 00:05:28.030 --> 00:05:33.970 April 24th. Yes, which is estimated I think right now somewhere early 00:05:33.970 --> 00:05:37.190 May, May the 4th or something. May the 4th be with you. 00:05:37.190 --> 00:05:41.510 Sure, that would be a cool date. So that's when the signaling starts. And the 00:05:41.510 --> 00:05:46.510 signaling happens in you could say voting rounds, and a voting round is is two 00:05:46.510 --> 00:05:50.750 weeks, or you know one difficulty… uh adjustment period one retargeting period. 00:05:50.750 --> 00:05:56.540 Yeah now if 90 of the miners… or if 90% of the 00:05:56.540 --> 00:06:02.500 blocks in that voting period signal on bit number, I guess it's number two. 00:06:04.580 --> 00:06:05.460 One or two? 00:06:06.080 --> 00:06:11.440 Yeah, bit number two. Then, if that happens, Taproot is locked in. 00:06:12.120 --> 00:06:17.920 And locked in means that it's going to happen. So, you know, imagine the 00:06:17.920 --> 00:06:21.500 little gif with Ron Paul, I think. It's happening. 00:06:23.620 --> 00:06:24.000 But... 00:06:24.000 --> 00:06:29.220 The actual Taproot rules won't take effect immediately. They will take effect at 00:06:29.220 --> 00:06:30.060 block number 00:06:30.950 --> 00:06:37.360 706,632. 00:06:37.720 --> 00:06:40.720 Yes, which is estimated to be mined when? 00:06:41.390 --> 00:06:44.350 That would be November 12th this year. 00:06:45.640 --> 00:06:50.300 Right. That's going to differ a bit, of course, based on how fast blocks are 00:06:50.300 --> 00:06:54.260 going to be mined over the coming months. But it's going to be November, almost certainly. 00:06:54.440 --> 00:06:59.300 Yeah, which would be four years after the SegWit2x effort imploded. 00:06:59.300 --> 00:07:02.320 Right nice nice timing in that sense. 00:07:02.320 --> 00:07:08.020 Yeah every date is nice. Um okay so that's that's what the Speedy Trial does. So 00:07:08.020 --> 00:07:12.260 there's going to be every two weeks as a vote if 90 of the vote reaches, then 00:07:12.260 --> 00:07:16.540 that's the activation date. So it doesn't happen immediately and because it's a 00:07:16.540 --> 00:07:21.960 Speedy Trial uh it could also fail quickly. And that is in August. 00:07:21.960 --> 00:07:27.870 So if I think around August 11th, If the difficulty period after that or 00:07:27.870 --> 00:07:29.050 before that, I always forget, 00:07:30.290 --> 00:07:34.470 doesn't reach the goal, I think it's after, then... 00:07:34.470 --> 00:07:38.730 The difficulty period must have ended by August 11th, right? 00:07:40.510 --> 00:07:45.740 I think when August 11th is passed, 00:07:45.760 --> 00:07:50.620 it could still activate. But then the next difficulty period, it cannot. 00:07:51.480 --> 00:07:56.080 So I think the rule is at the end of a difficulty period, you start counting. 00:07:56.990 --> 00:08:02.770 And if the result is a failure, then if it's after August 11, 00:08:03.050 --> 00:08:07.690 you give up. But if it's not yet August 11, you enter the next round. 00:08:08.940 --> 00:08:13.580 Okay, wait. So if the first block of a new difficulty period is mined on August 00:08:13.580 --> 00:08:16.480 10, will that difficulty period still count? 00:08:16.640 --> 00:08:20.900 Yeah, that's right. And I think that's one of the subtle changes made to BIP 9 to 00:08:20.900 --> 00:08:23.100 make BIP 9 easy to reason about. 00:08:23.830 --> 00:08:24.350 I see. 00:08:24.350 --> 00:08:27.290 Because I think it used to be the other way around where you would first check 00:08:27.290 --> 00:08:32.950 the date. But if it was past the date, you would give up. But if it was before 00:08:32.950 --> 00:08:36.030 the date, you would still count. And now I think it's the other way around. So 00:08:36.030 --> 00:08:36.550 it's a bit simpler. 00:08:37.070 --> 00:08:41.530 I see. Okay, so there's going to be a signaling window of about three months. 00:08:41.730 --> 00:08:42.250 That's right. 00:08:42.570 --> 00:08:46.830 And then if in any difficulty period within that signaling window of three 00:08:46.830 --> 00:08:52.870 months, 90% of hash power is reached, Taproot will activate in November of this year. 00:08:53.270 --> 00:08:53.750 Yes. 00:08:54.110 --> 00:08:56.010 Right? I think that covers Speedy Trial. 00:08:56.270 --> 00:09:00.050 That's right. And the threshold is 90%, as we said. Like normally with BIP 9, 00:09:00.210 --> 00:09:02.630 it's 95%, but it's been lowered to 90. 00:09:02.950 --> 00:09:05.430 Yeah. What happens if the threshold is not met? 00:09:06.820 --> 00:09:07.300 Nothing. 00:09:07.800 --> 00:09:08.220 Great. 00:09:09.170 --> 00:09:12.550 Which means anything could still happen, right? So people could deploy new 00:09:12.550 --> 00:09:16.370 versions of software, try another bit or try it, et cetera. 00:09:16.690 --> 00:09:18.350 Yeah. I just wanted to clarify that. 00:09:18.610 --> 00:09:20.610 It does not mean that Taproot is canceled. 00:09:21.050 --> 00:09:26.930 Yeah. If the threshold isn't met, then this specific software client will 00:09:26.930 --> 00:09:31.510 just do nothing. But, you know, Bitcoin Core developers and the rest of the 00:09:31.510 --> 00:09:35.310 Bitcoin community can still figure out new ways to activate Taproot. 00:09:35.550 --> 00:09:41.070 Yeah, exactly. It's kind of a win-win. Well, I don't know if it's win-win, but 00:09:41.070 --> 00:09:46.610 the idea is it's a low-cost experiment. If it wins, we get Taproot. If not, then 00:09:46.610 --> 00:09:49.130 we have some more information as to why we don't. 00:09:49.330 --> 00:09:53.890 Yes. I also want to clarify, we don't know what that's going to look like yet. 00:09:54.610 --> 00:09:58.430 That will have to be figured out then, or we can start figuring it out now, but 00:09:58.430 --> 00:10:00.170 that hasn't been decided yet. 00:10:00.270 --> 00:10:00.650 Exactly. 00:10:00.930 --> 00:10:06.770 What redeployment will look like. Okay, so... This week, another client was also launched. 00:10:09.790 --> 00:10:13.170 There's a lot of debate on the name. I think we're just going to call it the 00:10:13.170 --> 00:10:14.050 LOT=true client. 00:10:14.510 --> 00:10:15.670 That sounds good to me. 00:10:15.850 --> 00:10:21.230 It derives from this sort of technical and philosophical difference about how 00:10:21.230 --> 00:10:26.930 soft forks should be activated in the first place. And this client 00:10:26.930 --> 00:10:29.810 uses, you guessed it, LOT=true. 00:10:32.760 --> 00:10:37.900 The specifics of this. So a LOT=true, just to sort of spoil that before we get 00:10:37.900 --> 00:10:43.590 into specifics, a LOT=true means that if the signaling window 00:10:43.590 --> 00:10:48.830 is over, by the end of the signaling window, nodes will start to reject any 00:10:48.830 --> 00:10:52.010 blocks that don't signal. They'll only accept blocks that signal. 00:10:52.410 --> 00:10:52.850 Exactly. 00:10:52.850 --> 00:10:56.410 That's sort of the main difference. But let's get into the specifics here about a 00:10:56.410 --> 00:10:57.170 LOT=true client. 00:10:57.590 --> 00:11:03.440 Yeah. So in the beginning, it is the same. That is... In principle it's the same, 00:11:03.440 --> 00:11:06.860 there's a theoretical possibility that it's not if miners do something really 00:11:06.860 --> 00:11:10.420 crazy, but it starts at a certain block height. 00:11:11.060 --> 00:11:16.980 Um yeah so we just mentioned that Bitcoin Core… and so this is Bitcoin 00:11:16.980 --> 00:11:22.760 Core 21.1 uh starts its signaling window on the first difficulty period 00:11:22.760 --> 00:11:28.650 after April 24th, and this uh LOT=true client 00:11:28.650 --> 00:11:34.460 will also in practice, start its signaling window on the first difficulty 00:11:34.460 --> 00:11:40.360 period after April 24th, except that April 24th isn't specified specifically. 00:11:40.820 --> 00:11:46.260 They just pick the specific block height that is expected to be the first one 00:11:46.260 --> 00:11:47.560 after April 24th. 00:11:47.760 --> 00:11:51.340 Exactly. So they pick 681,408. 00:11:51.500 --> 00:11:56.960 Yeah. So it's specified as a block height instead of sort of indirectly through 00:11:56.960 --> 00:11:57.840 using a date. 00:11:58.160 --> 00:12:02.120 Yeah, but in all likelihood, that's going to be the exact same moment. So both 00:12:02.120 --> 00:12:07.140 the Speedy Trial and the BIP 8, sorry, the LOT=true client, will start signaling 00:12:07.140 --> 00:12:08.780 the voting periods at the same time. 00:12:08.960 --> 00:12:09.280 Yes. 00:12:09.480 --> 00:12:13.560 And the voting periods themselves, they vote on the same bit. They both vote on 00:12:13.560 --> 00:12:14.300 bit two. 00:12:15.780 --> 00:12:19.780 They both have a threshold of 90%. And... 00:12:21.970 --> 00:12:27.570 Also, if the vote is true, then it also has a delayed activation. 00:12:27.870 --> 00:12:33.010 So the delayed activation is a block height in both scenarios, in both the Speedy 00:12:33.010 --> 00:12:35.430 Trial and in the LOT=true variant. 00:12:35.850 --> 00:12:41.390 Yeah, so it's both that 12th November or November activation anyway. So if... 00:12:43.040 --> 00:12:48.480 Taproot, if miners signal readiness for Taproot within the Speedy Trial period, 00:12:48.800 --> 00:12:53.240 both of these clients will just activate Taproot in November on the exact same date. 00:12:53.380 --> 00:12:53.480 Yeah. 00:12:53.600 --> 00:12:54.320 Exact same block. 00:12:54.500 --> 00:12:56.120 Exactly. So in that sense, they're identical. 00:12:56.540 --> 00:12:57.060 Yes. 00:12:58.500 --> 00:12:59.780 But they are also different. 00:13:00.040 --> 00:13:03.340 Let's get into the first big difference. Well, we already mentioned one 00:13:03.340 --> 00:13:07.780 difference, which is the very, very, very subtle sort of difference between 00:13:07.780 --> 00:13:12.900 starting at a height or the thing we just mentioned. Now let's get into a bigger 00:13:12.900 --> 00:13:13.340 difference. 00:13:13.560 --> 00:13:18.960 Right, because there is also a height for a timeout in this [unclear] and that's 00:13:18.960 --> 00:13:24.030 also a block. But not only is that a block, you know, that could be a slight 00:13:24.030 --> 00:13:28.090 difference, especially when it's a long time period, right? In the beginning, if 00:13:28.090 --> 00:13:31.210 you use block height or time date, you can guess very accurately. But if it's a 00:13:31.210 --> 00:13:32.650 year ahead, then you can't. 00:13:33.090 --> 00:13:33.190 Yeah. 00:13:33.630 --> 00:13:37.690 But this is actually almost two years ahead, this block height that they have in 00:13:37.690 --> 00:13:40.350 there. So it goes on much longer. 00:13:40.570 --> 00:13:41.970 Two years from now, you mean? 00:13:42.190 --> 00:13:42.330 Yeah. 00:13:42.490 --> 00:13:43.710 Well, one and a half, but yeah. 00:13:44.420 --> 00:13:48.580 Exactly. So in that sense, it doesn't really matter that they're using height 00:13:48.580 --> 00:13:54.360 because it's such a big difference anyway. But this is important. So they will 00:13:54.360 --> 00:13:57.600 keep signaling much longer than the Speedy Trial. 00:13:58.830 --> 00:14:03.030 which, well, we can get into the implications later, but basically they'll signal 00:14:03.030 --> 00:14:03.570 much later. 00:14:03.750 --> 00:14:08.130 Yeah, let's stick to the facts first and the implications later. So yeah, Speedy 00:14:08.130 --> 00:14:12.570 Trial, the Bitcoin Core thing, it will last for three months. And this one, the 00:14:12.570 --> 00:14:15.810 LOT=true client will allow signaling for 18 months. 00:14:16.050 --> 00:14:19.410 And then the biggest difference, of course, or well, the other big difference is 00:14:19.410 --> 00:14:24.370 that at the end of that 18 months, whereas the Speedy Trial will simply give up. 00:14:24.780 --> 00:14:30.780 And continue, the LOT=true will actually wait for miners who 00:14:30.780 --> 00:14:34.820 do signal which could be nobody or it could be everybody. Yeah so they'll 00:14:34.820 --> 00:14:40.700 only accept signaling blocks after these 18 months. Yeah so it's a little bit, 00:14:40.700 --> 00:14:46.220 um for those who are aware of sort of the whole block size war 00:14:46.220 --> 00:14:50.480 period it's a little bit like the BIP 148 client. 00:14:50.480 --> 00:14:56.220 Yeah it's pretty much the same with slightly… better tolerance, I think. Like 00:14:56.220 --> 00:15:01.630 the... The UASF client required every single block to signal, whereas this one 00:15:01.630 --> 00:15:05.810 requires 90% to signal. But in practice, if… if… you know, if… you're the miners 00:15:05.810 --> 00:15:09.750 in the last 10% of that window, I guess you you need to pay a bit more attention. 00:15:10.010 --> 00:15:10.870 But other than that, it's the same. 00:15:11.190 --> 00:15:16.630 Yeah, so that's why some people would call this the UASF client. It's the UASF 00:15:16.630 --> 00:15:22.510 client where the BIP 148 client was the UASF client for SegWit. This is sort of 00:15:22.510 --> 00:15:24.390 the UASF client for Taproot. 00:15:25.690 --> 00:15:30.850 I know that, for example, Luke Dashjr, who's been contributing to this client, 00:15:31.030 --> 00:15:35.570 doesn't like the term UASF in this context because there's also 18 months of just 00:15:35.570 --> 00:15:37.830 regular miner signaling. 00:15:39.030 --> 00:15:42.970 So did the UASF. It's a bit more patient than the UASF. 00:15:44.000 --> 00:15:48.480 Like I said, there's a lot of discussion on the names of the client and how 00:15:48.480 --> 00:15:52.520 people should call it or not call it. But just in general, some people have been 00:15:52.520 --> 00:15:54.760 calling it the UASF client and this is why. 00:15:55.340 --> 00:15:59.520 Okay. Yeah. So you can call it the slow UASF or something. Yeah. 00:16:00.240 --> 00:16:01.580 I've also seen the name 00:16:01.580 --> 00:16:06.340 user-enforced 00:16:06.340 --> 00:16:12.020 miner-activated soft fork. So that's... [unclear] or 00:16:12.020 --> 00:16:17.900 whatever there people are coming up with terms and names. I think the basic facts 00:16:17.900 --> 00:16:19.020 are clear now I hope. 00:16:19.020 --> 00:16:19.920 Yes. 00:16:19.920 --> 00:16:22.340 Okay, so let's get into the implications 00:16:23.820 --> 00:16:29.420 and in specific there are some potential incompatibilities between 00:16:29.420 --> 00:16:31.700 these two activation clients. 00:16:31.700 --> 00:16:32.620 Yeah for sure. 00:16:32.620 --> 00:16:38.600 Yeah so everyone agrees that Taproot is great. Everyone wants Taproot. Everyone 00:16:38.600 --> 00:16:43.640 agrees that it would be preferable if miners activate it. The only thing that 00:16:43.640 --> 00:16:48.020 there are still some disagreements on is sort of what's what's kind of the backup 00:16:48.020 --> 00:16:53.210 plan, and that's where the incompatibilities come in. Am I saying that right? Do you agree? 00:16:53.210 --> 00:16:54.290 Yeah, I think so. 00:16:54.290 --> 00:16:57.680 Okay, so what are the incompatibilities? 00:16:57.680 --> 00:17:03.180 Yeah, so in the case where the Speedy Trial does not activate um 00:17:03.180 --> 00:17:04.160 so 00:17:04.160 --> 00:17:08.580 First of all and I already mentioned this but just to emphasize emphasize this, 00:17:08.580 --> 00:17:14.230 if Speedy Trial activates Taproot there are no incompatibilities. Both clients 00:17:14.230 --> 00:17:19.550 are happily using Taproot starting in November. And this seems pretty likely 00:17:19.550 --> 00:17:25.290 because 90% of miners, mining pools, I should say, 00:17:25.470 --> 00:17:30.830 have already indicated that they support Taproot. So likely there's no big deal 00:17:30.830 --> 00:17:36.430 here. Everything will turn out fine. If Speedy Trial doesn't succeed in 00:17:36.430 --> 00:17:42.140 activating Taproot, that's where we enter a phase where... We're going to 00:17:42.140 --> 00:17:44.440 start to look at potential incompatibilities. 00:17:44.940 --> 00:17:50.160 Yeah, for sure. So imagine one scenario where Speedy Trial fails and, you know, 00:17:51.150 --> 00:17:55.540 probably Bitcoin Core people will think about that for a while and think about 00:17:55.540 --> 00:18:01.060 some other possibilities. But for some reason, miners get wildly enthusiastic 00:18:01.060 --> 00:18:05.640 right after Speedy Trial fails and start signaling at 90%. 00:18:05.640 --> 00:18:06.120 Right. 00:18:06.340 --> 00:18:11.720 Now, as far as Bitcoin Core is concerned, Taproot never activated. Where as far 00:18:11.720 --> 00:18:17.640 as the speed… as far as the UASF or a LOT=true client, Taproot did 00:18:17.640 --> 00:18:18.400 just activate. 00:18:18.400 --> 00:18:22.720 Yeah so let's say in month four, you know we have three months of Speedy Trial, 00:18:22.720 --> 00:18:28.720 and in month four miners suddenly signal readiness for Taproot that 00:18:28.720 --> 00:18:34.080 means Bitcoin Core doesn't care anymore. Bitcoin Core at least a 21.1 client 00:18:34.080 --> 00:18:39.170 isn't looking at the signaling anymore. But this LOT=true client is. So on the 00:18:39.170 --> 00:18:43.930 LOT=true client, Taproot will be activated in November, while on this Bitcoin 00:18:43.930 --> 00:18:45.630 Core client, it will not. Yeah. 00:18:45.730 --> 00:18:49.590 And then, of course, if you are using that LOT=true client and you start 00:18:49.590 --> 00:18:54.750 immediately using Taproot at that moment because you're very excited and 00:18:54.750 --> 00:19:00.250 you see all these blocks coming in, you may or may not lose your money 00:19:00.250 --> 00:19:05.930 because... Anybody who's running the regular Bitcoin Core client will accept 00:19:05.930 --> 00:19:08.870 those thefts from Taproot addresses essentially. 00:19:08.870 --> 00:19:13.950 Yeah well in this case it matters what miners are doing as well right? So 00:19:13.950 --> 00:19:14.690 Yes exactly. 00:19:14.690 --> 00:19:18.990 If miners signal readiness because they're actually ready and they're actually 00:19:18.990 --> 00:19:24.170 gonna enforce Taproot then it's fine. Then there's no issue because they'll just 00:19:24.170 --> 00:19:29.660 you know, enforce the software and even Bitcoin Core 21.1 nodes will follow 00:19:29.660 --> 00:19:35.460 this chain and the Taproot LOT=true client will also enforce and everyone's still 00:19:35.460 --> 00:19:39.460 happy on the same chain. The only scenario where this is a problem which you just 00:19:39.460 --> 00:19:45.340 described, if it is if… miners do signal readiness but they aren't actually 00:19:45.340 --> 00:19:46.440 going to enforce… 00:19:46.440 --> 00:19:46.780 Yeah. 00:19:47.230 --> 00:19:48.250 The Taproot rules. 00:19:48.250 --> 00:19:52.390 The problem is of course in general with soft forks but especially if it's you 00:19:52.390 --> 00:19:56.850 know not everybody's on the same page about what the rules are, is you only know 00:19:56.850 --> 00:19:59.890 that it's enforced when it's actually enforced. You don't know if it's going to 00:19:59.890 --> 00:20:04.030 be enforced in the future. So this would create a conundrum for everybody else 00:20:04.030 --> 00:20:07.730 because then the question is okay what to do? One thing you could do at that 00:20:07.730 --> 00:20:11.930 point is saying well obviously Taproot is activated so let's just release a new 00:20:11.930 --> 00:20:16.880 version of Bitcoin Core that just says okay retroactively it activated. It could 00:20:16.880 --> 00:20:22.740 just be a BIP 9 soft fork repeating the same bit, but slightly later. 00:20:22.880 --> 00:20:26.500 Or could you say, no, we know it activated. We'll just hard code the flag date. 00:20:26.740 --> 00:20:29.800 The problem is between the time you... 00:20:29.800 --> 00:20:32.880 It could just be a second Speedy Trial, whatever. Everything would work in that 00:20:32.880 --> 00:20:33.300 case, right? 00:20:34.070 --> 00:20:38.850 Well, yeah, there is a problem with reusing the same bit number within a short 00:20:38.850 --> 00:20:44.720 period of time. So because it would be exactly the week after... In a scenario we 00:20:44.720 --> 00:20:49.040 talked about, it may not be possible to use the same bit. And so then you have a 00:20:49.040 --> 00:20:54.020 problem because you can't actually check that specific bit, but there's no signal 00:20:54.020 --> 00:20:58.020 on any of the other bits. So that would create a bit of a headache. But the other 00:20:58.020 --> 00:21:01.580 solution would be very simple to say, okay, it apparently activated. So we'll 00:21:01.580 --> 00:21:05.720 just hard code the block date and activate it then. The problem is, what if 00:21:05.720 --> 00:21:11.140 between the time that... the community decides, let's do this. And the moment 00:21:11.140 --> 00:21:16.770 that software is released and somewhat widely deployed, one or more miners 00:21:16.770 --> 00:21:20.170 say, actually, we're going to start stealing these Taproot coins. 00:21:21.470 --> 00:21:26.490 You'd get a massive clusterfuck in terms of agreeing on the chain. Now, 00:21:27.310 --> 00:21:31.370 miners would not be incentivized to do this, right? Because why would you 00:21:31.370 --> 00:21:36.640 deliberately create complete chaos if you just signaled for a soft fork? But it 00:21:36.640 --> 00:21:40.620 is a very scary situation, and it might make it scary to make the release. 00:21:40.920 --> 00:21:44.980 Because if you do make the release, but miners start playing the shenanigans, 00:21:45.320 --> 00:21:50.440 well, what do you do then? Do you accept a huge reorg at some point? Or do you 00:21:50.440 --> 00:21:54.900 give up and consider it not deployed, but then people lose their money, and 00:21:54.900 --> 00:21:59.260 you've released a client that you now have to hard fork from, technically? So 00:21:59.260 --> 00:22:00.780 it's not a good scenario. 00:22:01.510 --> 00:22:06.290 It gets complicated in scenarios like this, also with game theory and with 00:22:06.290 --> 00:22:12.190 economics. You know, even if miners would choose to steal, they risk stealing 00:22:12.190 --> 00:22:16.390 coins on a chain that could be re-orged. So now they've just mined a chain that 00:22:16.390 --> 00:22:21.870 could be re-orged if other miners do enforce the Taproot rule. So it gets weird. 00:22:22.070 --> 00:22:26.570 It gets, you know, it's a discussion about economic incentives and game theory in 00:22:26.570 --> 00:22:32.460 that scenario. Personally, I think it's pretty unlikely that something like 00:22:32.460 --> 00:22:35.920 this would happen, but it's at least technically possible, and it's something to 00:22:35.920 --> 00:22:36.600 be aware of. 00:22:37.640 --> 00:22:42.840 Yeah, it does make you wonder whether, as a miner, it's smart to signal 00:22:42.840 --> 00:22:47.940 immediately after the Speedy Trial. Because this LOT=true client allows for two 00:22:47.940 --> 00:22:51.880 years anyway. So if the only reason you're signaling is because this client 00:22:51.880 --> 00:22:55.640 exists, then I would strongly suggest not doing it immediately after the Speedy 00:22:55.640 --> 00:23:00.250 Trial. But maybe waiting a little bit until there's some consensus about what to do next. 00:23:00.550 --> 00:23:05.760 Yeah, one thing you mentioned, and I want to quickly address that and emphasize 00:23:05.760 --> 00:23:11.260 that, is that this risk always exists for any soft fork. 00:23:11.600 --> 00:23:11.820 Yes. 00:23:11.980 --> 00:23:16.060 Miners can always sort of false signal, and then you know they could have done it 00:23:16.060 --> 00:23:20.300 with SegWit, for example, false signal, and then steals coins from SegWit 00:23:20.300 --> 00:23:25.710 outputs, and then old nodes will notice difference. So that's… always a risk. I 00:23:25.710 --> 00:23:31.670 think the difference here is that Bitcoin Core 21.1 users in 00:23:31.670 --> 00:23:35.310 this scenario might think that they're running a new node and from their 00:23:35.310 --> 00:23:40.810 perspective they are running an update node and still they're sort of running the 00:23:40.810 --> 00:23:46.350 same risks as previously all only sort of outdated nodes would runs. 00:23:46.350 --> 00:23:51.710 Well I'd be mostly worried about the potential 0.21.2 00:23:51.710 --> 00:23:57.670 users who are installing the successor to Speedy Trial, which retroactively 00:23:57.670 --> 00:24:03.430 activates Taproot, perhaps, that group is just very uncertain of what the rules are. 00:24:04.500 --> 00:24:05.780 Sorry, which group is this? 00:24:05.980 --> 00:24:11.500 So if the Speedy Trial fails and then it's signaled, right? So there might be a 00:24:11.500 --> 00:24:15.680 new release and people would install that new release, but then it's not clear 00:24:15.680 --> 00:24:17.420 whether that new release would be safe or not. 00:24:19.200 --> 00:24:23.020 Because that very new release would be the only one who would actually think that 00:24:23.020 --> 00:24:25.700 Taproot is active, as well as [unclear]. 00:24:25.780 --> 00:24:27.040 Yeah, as well as [unclear]. 00:24:27.120 --> 00:24:29.820 But now we don't know what the miners are running, and we don't know what the 00:24:29.820 --> 00:24:34.760 exchanges are running, because this is very new, right? This would be done... you 00:24:34.760 --> 00:24:38.300 know in a period of weeks rather than right now we have a six month… 00:24:38.300 --> 00:24:40.820 No hang on hang on, because I guess… 00:24:40.820 --> 00:24:42.280 The activation date would still be in November. 00:24:42.280 --> 00:24:46.580 Yeah it would still be November. So there's still room to sort of prepare in that case. 00:24:46.580 --> 00:24:50.580 Yeah okay okay then I guess what I said before is nonsense. And the easier 00:24:50.580 --> 00:24:54.200 solution would be to do a flag date where the new release would say okay it's 00:24:54.200 --> 00:24:58.180 just going to activate on November 12th or whatever that block height is without 00:24:58.180 --> 00:25:02.340 any signaling because the signaling exists but people have different 00:25:02.340 --> 00:25:06.790 interpretations about it. Yeah that could be a way. Okay. 00:25:06.790 --> 00:25:10.390 I… I'm still completely clear about what we're talking about here but I'm not 00:25:10.390 --> 00:25:14.270 sure if our listeners are catching up at this point. All right, so we sort of 00:25:14.270 --> 00:25:18.990 very briefly um re 00:25:18.990 --> 00:25:24.750 recap… a bit recap. Yeah so if miners 00:25:24.750 --> 00:25:29.730 activate during the Speedy Trial periods then everything is fine everyone is 00:25:29.730 --> 00:25:30.250 consensus. 00:25:30.250 --> 00:25:32.710 Yeah and the new rules take effect in November. 00:25:33.070 --> 00:25:38.130 Yeah, if miners activate after the Speedy Trial period, then there is a 00:25:38.130 --> 00:25:43.650 possibility that the LOT=true client and the Bitcoin Core 21.1 client 00:25:43.650 --> 00:25:49.570 won't be in consensus if an invalid Taproot block is ever mined. 00:25:50.330 --> 00:25:50.890 However... 00:25:50.800 --> 00:25:51.210 No, earlier. 00:25:53.330 --> 00:25:58.010 Because of the... Oh, no, you're right. Because they have no force signaling. 00:25:58.350 --> 00:26:02.150 Yeah, you're right. If an invalid Taproot transaction shows up after November... 00:26:02.480 --> 00:26:03.000 12? 00:26:03.300 --> 00:26:09.120 Yeah. And if that is mined and enforced by a majority of miners, only then, so 00:26:09.120 --> 00:26:14.320 then a majority of miners must have false signals, then the two clients can get 00:26:14.320 --> 00:26:15.040 out of consensus. 00:26:15.380 --> 00:26:15.560 Yes. 00:26:17.170 --> 00:26:20.970 This is just a technical, technically this is true. I personally think it's 00:26:20.970 --> 00:26:24.850 fairly unlikely. I'm not too concerned about this, but it's at least technically 00:26:24.850 --> 00:26:26.590 true and something people should be aware of. 00:26:26.590 --> 00:26:31.130 And so that scenario could be prevented, by saying, well, if we see this false 00:26:31.130 --> 00:26:35.750 signaling, like a week direct… or false quote unquote signaling, if we see this 00:26:35.750 --> 00:26:41.090 massive signaling a week after the Speedy Trial, then you could decide to release 00:26:41.090 --> 00:26:45.190 a flag date client, which just says we're just going to activate this November 00:26:45.190 --> 00:26:49.720 12th because apparently the miners want this. And otherwise we have no idea what 00:26:49.720 --> 00:26:50.440 to make of the signal. 00:26:52.620 --> 00:26:57.900 Yes. Well, I find it very hard to predict what Bitcoin Core developers in this 00:26:57.900 --> 00:26:59.160 case are going to decide. 00:26:59.380 --> 00:26:59.700 I agree. 00:26:59.900 --> 00:27:01.420 This is one possibility. 00:27:02.820 --> 00:27:07.560 Okay. That was sort of one way the two clients can become incompatible 00:27:07.560 --> 00:27:13.380 potentially and that there is another way which is maybe more likely or at least 00:27:13.380 --> 00:27:18.530 more... It's not as complicated. The other one is a little bit simple. 00:27:18.610 --> 00:27:22.510 Yeah, the other one is let's imagine that the Speedy Trial fails and the 00:27:22.510 --> 00:27:28.270 community does not have consensus of how to proceed next. And Bitcoin 00:27:28.270 --> 00:27:32.810 Core developers can see that. Like there's just ongoing discussion and nobody 00:27:32.810 --> 00:27:36.850 agrees. And maybe Bitcoin Core developers decide to therefore just wait and see. 00:27:37.170 --> 00:27:38.450 Yeah, miners aren't signaling. 00:27:39.030 --> 00:27:43.130 Yeah, or erratically, et cetera. Miners aren't signaling. 00:27:44.520 --> 00:27:48.480 The discussion still goes on. Nothing happens. Well, then this LOT=true mechanism 00:27:48.480 --> 00:27:49.020 kicks in. 00:27:50.500 --> 00:27:55.860 After 18 months? Yeah. So we're talking about November 2022 now. It's a long way 00:27:55.860 --> 00:27:58.940 off. But at some point, the LOT=true mechanism will kick in. 00:27:59.520 --> 00:28:03.480 Exactly. So those nodes will then, assuming the miners are still not signaling, 00:28:03.940 --> 00:28:04.820 they will just stop. 00:28:06.830 --> 00:28:12.250 Yeah, or may at least if there's… that… that's if there's literally no LOT=true 00:28:12.250 --> 00:28:15.450 blocks, basically, if there are no signaling blocks. 00:28:15.550 --> 00:28:21.030 Now, in the other scenario where miners do massively start signaling, now we're 00:28:21.030 --> 00:28:24.670 kind of back to that previous scenario where suddenly there's a lot of miners 00:28:24.670 --> 00:28:30.370 signaling on bit number one. So maybe the fork is active, 00:28:30.370 --> 00:28:35.430 but now there's no delay because... If the signaling happens anywhere after 00:28:35.430 --> 00:28:41.270 November 12th, the LOT=true client will immediately activate Taproot or 00:28:41.270 --> 00:28:43.690 after one adjustment period. 00:28:45.070 --> 00:28:50.610 Well, let's be clear because I'm not sure I'm following you, but I think 00:28:50.610 --> 00:28:54.050 what you mean is that in that case, okay, repeat what you said. 00:28:54.170 --> 00:28:59.810 Yeah, so let's say in this case, in December of this year, The miners suddenly 00:28:59.810 --> 00:29:01.610 start signaling because... 00:29:01.610 --> 00:29:02.890 In September of this year. 00:29:03.090 --> 00:29:05.030 December of this year. So at the end of this year. 00:29:05.210 --> 00:29:05.390 Yeah. 00:29:05.590 --> 00:29:07.730 But after the minimum activation height. 00:29:07.910 --> 00:29:08.090 Sure. 00:29:08.470 --> 00:29:13.450 So in December, they all start signaling. So then the Bitcoin Core client will 00:29:13.450 --> 00:29:17.890 ignore it, right? But the LOT=true thing, clients will say, okay, Taproot is 00:29:17.890 --> 00:29:20.470 active. So then we get... 00:29:20.470 --> 00:29:22.630 This is just the same scenario we just discussed. 00:29:22.710 --> 00:29:23.470 Well, except now there's no... 00:29:23.470 --> 00:29:26.370 Where it's only a problem if there's false signaling. Otherwise, it's fine. 00:29:27.430 --> 00:29:30.410 Yeah, there's a problem with this false signaling, but it is more complicated to 00:29:30.410 --> 00:29:34.550 resolve this one because that option of just releasing a new client with a flag 00:29:34.550 --> 00:29:38.770 date in it that is far enough into the future, that's no longer there because 00:29:38.770 --> 00:29:43.810 it's potentially active immediately. And if you do a release, but then suddenly a 00:29:43.810 --> 00:29:48.690 miner starts not enforcing the rules, you get this confusion that we talked about 00:29:48.690 --> 00:29:53.900 earlier. And then we were able to solve it by just making a flag day. So this 00:29:53.900 --> 00:29:56.600 would be even messier. Maybe it's also even less likely. 00:29:56.820 --> 00:30:02.300 It's pretty similar to the previous scenario, but even a little bit more 00:30:02.300 --> 00:30:04.420 difficult. Less obvious how to solve it. 00:30:04.580 --> 00:30:08.200 Yeah, I think it's messier because it is less obvious how you would do a flag day 00:30:08.200 --> 00:30:13.380 release in Bitcoin Core in that scenario because it immediately activates. 00:30:13.680 --> 00:30:15.980 But that's not where I wanted to go with this. 00:30:16.330 --> 00:30:20.130 Well, you wanted to go to, for some scenario, miners would wait all the way until the end. 00:30:20.250 --> 00:30:20.410 Yes. 00:30:20.410 --> 00:30:21.110 Until they start signaling. 00:30:21.270 --> 00:30:22.110 That's where I wanted to go. 00:30:22.670 --> 00:30:26.130 Which is where the mandatory signaling kicks in. So if there's no mandatory 00:30:26.130 --> 00:30:32.130 signaling, then the LOT=true nodes will stop until 00:30:32.130 --> 00:30:37.260 somebody mines a block that they like to see, which is a block that signals. Now, 00:30:37.380 --> 00:30:42.840 if they do see this block that signals, we're back in the previous example where 00:30:42.840 --> 00:30:47.840 suddenly the regular Bitcoin Core nodes see this signaling, but they 00:30:47.840 --> 00:30:52.840 ignore it. And now there's a group of nodes that believe Taproot is active, 00:30:53.200 --> 00:30:59.280 and there's a group of nodes that don't. So somebody has to then decide what to do with it. 00:31:01.670 --> 00:31:04.130 You're still talking about false signaling here? 00:31:05.880 --> 00:31:06.540 Well, no. 00:31:06.740 --> 00:31:07.640 Otherwise, there's no problem. 00:31:08.360 --> 00:31:14.200 There is, because even if the signaling is genuine, you still want there 00:31:14.200 --> 00:31:19.660 to be a Bitcoin Core release, probably, that actually says, okay, we have Taproot 00:31:19.660 --> 00:31:23.940 now. But the question is, when do we have Taproot now, according to that release? 00:31:24.420 --> 00:31:28.120 What is the safe date to put in there? You could do it retroactively. 00:31:28.120 --> 00:31:28.900 Whenever they want. 00:31:30.920 --> 00:31:32.780 Yeah, well then the problem is what happens… 00:31:32.780 --> 00:31:37.960 The point is, if miners are actually enforcing the new rules then the the chain 00:31:37.960 --> 00:31:38.660 will stay together. 00:31:38.660 --> 00:31:39.200 That's true. 00:31:39.200 --> 00:31:43.740 And it's sort of up to Bitcoin Core I guess to implement it whenever they've… 00:31:43.740 --> 00:31:48.300 Yeah but again the problem is with this signaling, is you don't know if it's 00:31:48.300 --> 00:31:52.140 active until somebody decides to try and break the rules right? Yeah. 00:31:52.140 --> 00:31:56.750 Yeah but my assumption was that there weren't false signaling, so then they'll 00:31:56.750 --> 00:32:00.170 just create the longest chain with the valid rules anyways. 00:32:00.590 --> 00:32:02.970 Of course. The problem with that is that it's unknowable. 00:32:04.750 --> 00:32:10.410 The scenario I really wanted to get to, Sjors, is the very simple scenario that 00:32:10.410 --> 00:32:14.790 the majority of miners isn't going to signal when the 18 months are up. 00:32:15.010 --> 00:32:15.310 Exactly. 00:32:15.450 --> 00:32:19.170 In that case, they're going to create a long chain, the longest chain that the 00:32:19.170 --> 00:32:23.730 Bitcoin Core nodes, the Bitcoin Core 21.1 nodes, I guess in this case, are going 00:32:23.730 --> 00:32:28.470 to follow, while the LOT=true nodes are only going to accept blocks that do 00:32:28.470 --> 00:32:34.080 signal, which may be... Either zero or at least fewer or, well, 00:32:34.200 --> 00:32:38.260 if it's a majority, then there's no split. But if it's not a majority, then we 00:32:38.260 --> 00:32:38.700 have a split. 00:32:38.960 --> 00:32:42.680 Yeah, and that chain would get further and further and further behind. So then 00:32:42.680 --> 00:32:48.420 the incentive to make a release to account for that would be quite small, I 00:32:48.420 --> 00:32:53.160 think. Well, it depends. This is where your game theory comes in. But from a 00:32:53.160 --> 00:32:57.940 safety point of view, if you now make a release that says, oh, by the way, we 00:32:57.940 --> 00:33:02.170 retroactively consider Taproot active, well, that would cause a giant reorg. 00:33:03.270 --> 00:33:07.110 Well, if you just activate it, that wouldn't cause a giant reorg. But if you say, 00:33:07.190 --> 00:33:10.730 oh, by the way, we're going to retroactively mandate that signaling that you guys 00:33:10.730 --> 00:33:15.630 care about, that would cause a massive reorg, which would be unsafe. So that 00:33:15.630 --> 00:33:17.850 would not be something that would be released probably. 00:33:21.450 --> 00:33:22.950 So that's a very messy situation. 00:33:23.150 --> 00:33:28.830 There are messy potential scenarios. I want to emphasize to our dear 00:33:28.830 --> 00:33:34.130 listeners, none of this is going to happen in a couple of... 00:33:34.260 --> 00:33:35.920 months next couple of months. 00:33:35.920 --> 00:33:36.620 And hopefully never. 00:33:36.620 --> 00:33:37.640 And hopefully never. 00:33:37.640 --> 00:33:41.340 So we'll throw in a few other bad scenarios and then I guess we can go into some 00:33:41.340 --> 00:33:42.520 other topics but yeah. 00:33:42.520 --> 00:33:47.280 Now, I want to mention real quick that the reason I'm not too concerned about 00:33:47.280 --> 00:33:52.870 these kinds of really bad scenarios playing out is because I think if it seems 00:33:52.870 --> 00:33:56.530 even slightly likely that there might be a coin split or anything like that there 00:33:56.530 --> 00:34:00.530 will probably be futures markets and these futures markets will probably make it 00:34:00.530 --> 00:34:06.500 very clear to everyone if the alternative chain stands a chance or, you know, 00:34:06.580 --> 00:34:11.860 they'll inform miners on what to mine and prevent the split that way. Or I think, 00:34:12.120 --> 00:34:16.520 I feel pretty confident about sort of the collective wisdom of the market to 00:34:16.520 --> 00:34:21.740 warn everyone about potential scenarios and it will probably work out 00:34:21.740 --> 00:34:23.880 fine. That's kind of my... 00:34:25.120 --> 00:34:25.960 general assessment. 00:34:26.180 --> 00:34:28.900 Yeah, I mean, the problem with this sort of stuff is if it doesn't work out fine, 00:34:28.920 --> 00:34:30.160 it's really, really bad. 00:34:30.320 --> 00:34:30.580 Yes. 00:34:30.800 --> 00:34:33.920 And then we get to say retroactively, well, I guess it didn't work out fine. 00:34:35.720 --> 00:34:36.740 So one little... 00:34:36.740 --> 00:34:41.860 I want to bring something up before you bring up whatever you wanted to bring up. 00:34:42.280 --> 00:34:47.280 I've seen some concerns by Bitcoin Core developers about the development process 00:34:47.280 --> 00:34:52.410 of the LOT=true client. And I think this gets down to the sort of... Gitian 00:34:52.410 --> 00:34:57.610 building, Gitian signing, which we also discussed in our episode on that specific topic. 00:34:57.970 --> 00:35:02.490 Yeah, we talked about the need for software to be open source, to be easy to audit. 00:35:02.790 --> 00:35:08.190 Yeah, okay. Sort of quickly give your view on that in this context. 00:35:08.610 --> 00:35:13.570 So basically the change that they made relative to the main Bitcoin Core client 00:35:13.570 --> 00:35:17.530 is not huge. And you can see it on GitHub. So in that sense, that part of the 00:35:17.530 --> 00:35:21.820 open source, I think is... reasonably doable to verify. I think that code has had 00:35:21.820 --> 00:35:24.620 less review, but not zero review. 00:35:25.340 --> 00:35:27.140 Less than Bitcoin Core is what you mean? 00:35:27.300 --> 00:35:30.000 Yeah, exactly. But much more than the UASF. 00:35:31.130 --> 00:35:32.190 A LOT=true client. 00:35:32.570 --> 00:35:35.370 No, I mean much more than the 2017 UASF. 00:35:35.430 --> 00:35:35.890 Oh, more than that? 00:35:36.010 --> 00:35:36.430 I would say. 00:35:36.610 --> 00:35:36.970 Right, okay. 00:35:37.890 --> 00:35:40.730 And besides, the idea has been studied a bit longer. 00:35:42.590 --> 00:35:45.950 But then the second problem is how do you know that what you're downloading isn't 00:35:45.950 --> 00:35:49.890 malware? And that's where you get release. Well, there's two measures there. 00:35:50.010 --> 00:35:54.090 There's release signatures. Now the website there, I think, explains pretty well 00:35:54.090 --> 00:35:58.570 how to check those. So I think they're signed by Luke Dashjr and by the other 00:35:58.570 --> 00:36:00.750 developer. So you can check that. 00:36:01.090 --> 00:36:02.270 Bitcoin Mechanic is the other. 00:36:02.570 --> 00:36:02.930 Okay. 00:36:02.930 --> 00:36:08.210 Well, okay. So actually it's released by Bitcoin Mechanic and Shinobi. And then 00:36:08.210 --> 00:36:09.810 Luke Dashjr is sort of the... 00:36:12.050 --> 00:36:12.850 advisor, contributor. 00:36:13.330 --> 00:36:16.770 Yeah. So there's a, usually there's a, there's a binary file that you download 00:36:16.770 --> 00:36:21.470 and then there's a file with checksums in it. And that file with checksums is 00:36:21.470 --> 00:36:26.010 also signed by a known person. So if you have Luke's key or whatever they're key 00:36:26.010 --> 00:36:29.410 and you know them, then you can check that at least the binary you downloaded is 00:36:29.410 --> 00:36:30.590 not coming from a hacked website. 00:36:30.710 --> 00:36:31.050 Right. 00:36:31.250 --> 00:36:34.890 And then the second thing, because then you just have a binary and you know, they 00:36:34.890 --> 00:36:38.680 signed it, but… Who are they, right? So the second thing is you want to check 00:36:38.680 --> 00:36:41.880 that this code matches the binary. And that's where Gitian building comes in, 00:36:42.020 --> 00:36:43.940 which we talked about in an earlier episode. 00:36:44.080 --> 00:36:44.260 Right. 00:36:44.560 --> 00:36:48.880 Basically deterministic builds. So it takes a software, it takes a source code 00:36:48.880 --> 00:36:53.500 and it produces the binary. And then you sign or multiple people can then sign 00:36:53.500 --> 00:36:59.300 that indeed, according to them, this source code produces this binary. And the 00:36:59.300 --> 00:37:02.700 more people that confirm that, the more likely it is that they're not colluding. 00:37:02.960 --> 00:37:03.080 Yeah. 00:37:03.360 --> 00:37:08.790 Right. And so I think there's only two Gitian signatures for 00:37:08.790 --> 00:37:11.030 this other release so far. 00:37:11.170 --> 00:37:16.150 So the Bitcoin Core software is being Gitian signed by... 00:37:16.380 --> 00:37:18.280 I think 10 or 20 people. 00:37:18.420 --> 00:37:24.240 Yeah. A lot of the experienced Bitcoin Core developers that we know that 00:37:24.240 --> 00:37:28.840 have been developing the Bitcoin Core software for a while, maybe including you, 00:37:28.880 --> 00:37:29.500 did you sign it? 00:37:29.920 --> 00:37:31.420 The most recent release, yes. 00:37:34.270 --> 00:37:39.090 And, you know, you're kind of trusting that they're not all colluding and 00:37:39.090 --> 00:37:44.190 spreading malware, I guess. It still comes down to trust in that sense for most people. 00:37:44.410 --> 00:37:48.290 Yeah, a little bit. I mean, the thing is, I think if you're really contemplating 00:37:48.290 --> 00:37:51.690 running this type of alternative software, you really should be knowing what 00:37:51.690 --> 00:37:55.450 you're doing in terms of all these reorg scenarios. If you already know what 00:37:55.450 --> 00:37:59.090 you're doing in those terms, then just compile the thing from source. 00:38:00.440 --> 00:38:04.540 Because why not? If you're not able to compile things from source, you probably 00:38:04.540 --> 00:38:10.360 shouldn't be running this. But that's up to you. Uh I I'm not I'm not saying that 00:38:10.360 --> 00:38:13.660 I'm worried that they would be like I'm not worried that they're shipping malware 00:38:13.660 --> 00:38:18.180 of course, but um the thing is it's in general it's it's just a matter of time 00:38:18.180 --> 00:38:22.640 before somebody says oh I have a different version with LOT=happy, and please 00:38:22.640 --> 00:38:25.920 download it here and then it steals all your Bitcoin. So it's more the precedent 00:38:25.920 --> 00:38:29.820 this is setting that I'm worrying about then that this thing would actually have 00:38:29.820 --> 00:38:30.400 malware in it. 00:38:31.360 --> 00:38:37.220 Yeah that's fair. So maybe um sign it, 00:38:38.260 --> 00:38:38.700 Sjors? 00:38:38.700 --> 00:38:41.660 No, because I don't think this is a sane thing to release. 00:38:42.420 --> 00:38:43.380 Okay, fair enough. 00:38:43.740 --> 00:38:47.180 But that's just my opinion. I mean, everybody's free to run whatever they want to run. 00:38:49.460 --> 00:38:52.420 Was there any other thing you wanted to bring up? 00:38:52.920 --> 00:38:57.940 Yeah, basically, we talked about true signaling or false signaling on bit one, 00:38:57.940 --> 00:39:03.140 but a very real possibility, I think, is if this activation fails and we want to 00:39:03.140 --> 00:39:08.600 try something else, then we probably don't want to use the same bit, if it's 00:39:08.600 --> 00:39:13.540 before the timeout window. So that could create a scenario where you might start 00:39:13.540 --> 00:39:17.240 saying, okay, let's use another bit to do signaling. And then you could get some 00:39:17.240 --> 00:39:22.280 confusion where there's a new Bitcoin Core release that activates using bit 00:39:22.280 --> 00:39:27.020 three, for example. But the LOT=true folks don't see it because they're looking 00:39:27.020 --> 00:39:27.600 at bit one. 00:39:29.680 --> 00:39:31.700 That may or may not be an actual problem. 00:39:33.030 --> 00:39:37.310 The other thing is that there could be all sorts of other ways to activate this 00:39:37.310 --> 00:39:43.250 thing. One thing could be a flag day. So if Bitcoin Core were to release a flag 00:39:43.250 --> 00:39:48.970 day, then there won't be any signaling. So a LOT=true clients won't 00:39:48.970 --> 00:39:54.570 know that Taproot is active and they will demand signaling at some point, even 00:39:54.570 --> 00:39:55.730 though Taproot is already active. 00:39:56.720 --> 00:40:02.690 Yeah, your point being that we don't know what... Bitcoin Core will release 00:40:02.690 --> 00:40:07.450 after a Speedy Trial and what they might release might not necessarily be 00:40:07.450 --> 00:40:09.850 compatible with the LOT=true client. 00:40:10.090 --> 00:40:11.670 Exactly. Now, it's also true of course... 00:40:11.670 --> 00:40:13.850 I will say that works both ways, of course. 00:40:14.970 --> 00:40:20.850 Yeah, sure. I'm just reasoning from one point here. I would also say that in 00:40:20.850 --> 00:40:24.390 the event that Bitcoin Core releases something else that has pretty wide 00:40:24.390 --> 00:40:28.790 community support, I would imagine the people who are running the BIP 8 clients 00:40:28.790 --> 00:40:34.640 are not like sitting in a cave somewhere. They're probably the relatively 00:40:34.640 --> 00:40:38.600 active users that know that they can decide, okay, you know what? I'm just going 00:40:38.600 --> 00:40:43.310 to run this Bitcoin Core version again because there's a flag date in it, which 00:40:43.310 --> 00:40:45.410 is earlier than the force signaling. 00:40:46.760 --> 00:40:50.040 So I could imagine that they would decide to just run it or not. 00:40:50.200 --> 00:40:51.520 That also works both ways. 00:40:52.140 --> 00:40:57.600 Well, no, not really, because I am much more worried about people who are not 00:40:57.600 --> 00:41:01.560 following this discussion, who just default download whatever the newest version 00:41:01.560 --> 00:41:06.130 of Bitcoin Core is, or don't upgrade at all, right, who are still running, say, 00:41:06.210 --> 00:41:07.450 Bitcoin Core 0.15. 00:41:08.820 --> 00:41:12.800 I'm much more worried about that group than about the group that actively takes a 00:41:12.800 --> 00:41:16.280 stance in this thing. Because if you actively take a stance by running something 00:41:16.280 --> 00:41:21.400 else, then you know what you're doing. And so it's kind of up to you to stay up to date. 00:41:22.700 --> 00:41:27.100 But we have kind of a commitment towards all the users that if you're still 00:41:27.100 --> 00:41:31.660 running in your bunker the 0.15 version of Bitcoin Core, that nothing bad should 00:41:31.660 --> 00:41:35.120 happen to you if you just follow the most proof of work. 00:41:36.040 --> 00:41:41.020 Yes, that could also mean making it compatible with the LOT=true Client. 00:41:41.640 --> 00:41:46.640 No, because as far as the 0.15 node is concerned, 00:41:47.650 --> 00:41:49.850 there is no LOT=true Client. 00:41:53.690 --> 00:41:58.360 Well, okay. Do we want to get into all sorts of scenarios? 00:41:59.180 --> 00:42:04.830 The scenario that I'm most concerned about is that... The LOT=true chain, 00:42:05.110 --> 00:42:09.590 to call it that, if there's ever a split, will win, but only after a while, 00:42:09.730 --> 00:42:13.870 because then you get long reorgs. So this gets back to the sort of LOT=true 00:42:13.870 --> 00:42:16.910 versus LOT=false discussion in the first place. 00:42:16.950 --> 00:42:20.440 I can only see that happening with a massive price collapse of Bitcoin itself. 00:42:20.440 --> 00:42:26.380 But because if… if… if… the scenario comes to be where a LOT=true starts 00:42:26.380 --> 00:42:32.210 winning after delay, which requires a big reorg, I would say that… Yeah… if 00:42:32.210 --> 00:42:36.270 it's more likely to win, its relative price will go up because it's more likely 00:42:36.270 --> 00:42:40.730 to win. But because a bigger reorg is more disastrous for Bitcoin, the longer the 00:42:40.730 --> 00:42:46.110 reorg, the lower the Bitcoin price. So I think, yeah, that would be the bad 00:42:46.110 --> 00:42:49.750 scenario. If there is a thousand block reorg or more, then I think the Bitcoin 00:42:49.750 --> 00:42:53.670 price will just collapse to something very low where we don't really care whether 00:42:53.670 --> 00:42:57.800 the LOT=true client wins or not. That's just... It doesn't matter anymore. 00:42:58.020 --> 00:43:01.800 Yeah, I agree with that. The reason I'm not concerned is what I mentioned before 00:43:01.800 --> 00:43:05.920 is because I think these things will be sorted out by futures markets well before 00:43:05.920 --> 00:43:07.320 it actually happens. 00:43:07.640 --> 00:43:11.780 Yeah, I guess the futures market would predict exactly that, basically saying, 00:43:11.820 --> 00:43:14.080 well, that would not be good. 00:43:15.740 --> 00:43:20.240 Depending on your confidence in futures market, which for me is not that amazing. 00:43:22.390 --> 00:43:23.310 Back on topic. 00:43:24.990 --> 00:43:28.900 Did we cover everything? More or less, I think. Was there anything else? 00:43:29.910 --> 00:43:35.230 I think so. I mean, we could still talk about this nitty difference between 00:43:35.230 --> 00:43:41.140 block height versus block time, which caused all this fiasco, but I don't 00:43:41.140 --> 00:43:42.200 think it's an interesting difference. 00:43:44.040 --> 00:43:48.300 I guess while we're recording the podcast, you might as well mention it. 00:43:49.060 --> 00:43:54.920 Okay. So when we first described the Speedy Trial, we kind of assumed 00:43:54.920 --> 00:44:00.260 it would be a… everything would be based on block height. So there would be a 00:44:00.260 --> 00:44:05.080 transformation from the way soft forks work right now, which is based on these 00:44:05.080 --> 00:44:09.780 medium times, to just block heights, which is conceptually simpler. 00:44:11.190 --> 00:44:15.410 But later on, there was some discussion between the people who were working on 00:44:15.410 --> 00:44:21.000 that, considering maybe the only Speedy Trial difference 00:44:21.000 --> 00:44:26.470 should be the activation height, and none of the other 00:44:26.470 --> 00:44:32.400 changes. So from the point of view of the existing code base, it's easier to make 00:44:32.400 --> 00:44:36.940 the Speedy Trial just adjust one parameter, which is an activation height, 00:44:37.140 --> 00:44:42.120 minimum activation height, versus the change where you change everything into 00:44:42.120 --> 00:44:45.910 block height, which is a bigger change from the existing code, even though the 00:44:45.910 --> 00:44:46.870 end result is easier. 00:44:49.360 --> 00:44:49.920 Yeah. 00:44:50.320 --> 00:44:54.440 So a purely block height-based approach is easier to understand, easier to 00:44:54.440 --> 00:44:59.280 explain what it's going to do, when it's going to do it. And there's some edge 00:44:59.280 --> 00:45:05.210 cases that are also easier. But to stay closer to the existing code base 00:45:05.370 --> 00:45:11.310 is easier for reviewers, somehow, somewhat. But the difference 00:45:11.310 --> 00:45:16.360 is pretty small, so I think they eventually decided... Some people decided on the 00:45:16.360 --> 00:45:19.660 coin toss and other people, I think, agreed even without the coin toss. 00:45:21.540 --> 00:45:22.160 There are 00:45:23.380 --> 00:45:27.820 arguments on both sides, but they seem to be pretty 00:45:27.820 --> 00:45:33.740 subtle, pretty nuanced. Like we mentioned, Speedy Trial is 00:45:33.740 --> 00:45:38.740 going to start on the same date anyways. So it doesn't seem to matter that much. 00:45:40.000 --> 00:45:44.540 And at some point, some developers were seriously considering just deciding 00:45:44.540 --> 00:45:49.320 through a coin flip, basically using the Bitcoin blockchain for that, picking a 00:45:49.320 --> 00:45:54.100 block in the near future and seeing if it ends with an even or uneven number, I 00:45:54.100 --> 00:45:57.200 guess. I don't know if that's literally what I did, but that would be one way of 00:45:57.200 --> 00:46:02.960 doing it. I think they did do the coin flip, but then after that, the sort of 00:46:02.960 --> 00:46:06.780 champions for both solution ended up agreeing anyways. 00:46:07.390 --> 00:46:10.830 Yeah, and they happen to agree on the same thing that the coin flip said, but yeah. 00:46:11.110 --> 00:46:15.590 Yeah. The main dissenter was Luke Dashjr, who 00:46:15.590 --> 00:46:21.470 feels strongly about using block 00:46:21.470 --> 00:46:22.650 heights consistently. 00:46:24.460 --> 00:46:29.780 And he also is of the opinion that the community had found consensus on that and 00:46:29.780 --> 00:46:34.580 that Bitcoin Core developers not using that is sort of going back on breaking 00:46:34.580 --> 00:46:37.700 community consensus, which... 00:46:37.700 --> 00:46:38.960 Well, that's his perspective. 00:46:39.140 --> 00:46:39.980 That's his opinion. 00:46:40.300 --> 00:46:45.720 If you look at the person who wrote the original pull request that was purely 00:46:45.720 --> 00:46:50.510 height-based, I think that was Andrew Chow, he closed his own pull request in 00:46:50.510 --> 00:46:51.510 favor of the... 00:46:53.020 --> 00:46:58.800 mixed solution that we have now. So if the person writing the code removes 00:46:58.800 --> 00:47:03.810 it himself, I think that's pretty clear. I mean, from my point of view, the 00:47:03.810 --> 00:47:07.430 people who are putting in the most effort should probably decide when it's 00:47:07.430 --> 00:47:08.150 something this trivial. 00:47:12.370 --> 00:47:15.030 Yeah either way I don't think it matters that much. 00:47:15.030 --> 00:47:19.370 So it seems like a minor point to me, but clearly not everyone agrees it's a 00:47:19.370 --> 00:47:19.870 minor point. 00:47:19.870 --> 00:47:23.530 No but that's sort of what bike shedding is about right? It wouldn't be bike 00:47:23.530 --> 00:47:27.010 shedding if everybody thought that it was irrelevant which color the bike shed had. 00:47:27.010 --> 00:47:32.890 Okay. Let's let's just let's leave the 00:47:32.890 --> 00:47:38.660 coin flip and uh the the time block height thing behind us because 00:47:38.660 --> 00:47:42.980 I think we covered everything and in maybe we shouldn't dwell on this last point. 00:47:42.980 --> 00:47:44.700 Okay is that it? 00:47:44.700 --> 00:47:45.580 I think so. 00:47:45.580 --> 00:47:48.400 I hope this was um at all clear for all this… 00:47:48.400 --> 00:47:51.600 I think we can very briefly still interject one thing that was brought up which 00:47:51.600 --> 00:47:54.200 is the time warp attack which I think we have… 00:47:54.200 --> 00:47:58.540 Oh yeah we don't mention that and that is somewhat relevant maybe. Yeah, in this context. 00:47:58.540 --> 00:48:00.740 Yeah one of the arguments against… 00:48:00.740 --> 00:48:04.320 using block time is that it opens the door to… 00:48:05.810 --> 00:48:10.290 time warp attacks where miners are basically faking the timestamps on the blocks 00:48:10.290 --> 00:48:14.650 they mine to pretend like it's a different time and date and that way they can, 00:48:14.750 --> 00:48:19.170 for example, just skip the signaling period altogether if they collude in doing that. 00:48:19.330 --> 00:48:22.450 Yeah, that sounds like an enormous amount of effort for no good reason, but it is 00:48:22.450 --> 00:48:26.630 an interesting scenario. We did an episode about the time warp attack a long time 00:48:26.630 --> 00:48:32.440 ago, back when I understood it, and there is a software proposal 00:48:32.440 --> 00:48:37.320 to get rid of it, that I don't think anybody objected to but also nobody bothered 00:48:37.320 --> 00:48:41.700 to actually implement and so one way to deal with this hypothetical scenario is 00:48:41.700 --> 00:48:46.080 that if it were to happen well then we deployed the soft fork against the time 00:48:46.080 --> 00:48:48.880 warp attack first and then we tried Taproot activation again. 00:48:49.200 --> 00:48:54.380 Yeah I mean the argument against that from someone like Luke is of course that 00:48:54.380 --> 00:48:59.580 yeah you can fix any bug but you can also just not include the bug in the first place. 00:48:59.580 --> 00:49:04.180 Well, it's nice to know that miners would be willing to use… if we know that 00:49:04.180 --> 00:49:08.180 miners are actually willing to exploit the time warp attack that is incredibly 00:49:08.180 --> 00:49:14.180 valuable app information. If they have a way to collude and and a motivation to 00:49:14.180 --> 00:49:19.040 use that attack then I think it's worth… the cost of that attack would just be 00:49:19.040 --> 00:49:22.540 pretty low right it would be delaying Taproot by a few months but we'd have this 00:49:22.540 --> 00:49:26.510 massive conspiracy unveiled. So I think that's a win. 00:49:26.980 --> 00:49:32.780 Yeah, the other thing, I think I'll just mention this because Luke 00:49:32.780 --> 00:49:38.360 believes, the way Luke sees it is that there was sort of already consensus on all 00:49:38.360 --> 00:49:43.860 sorts of things, on using BIP 8 and even sort of this LOT=true thing he saw as 00:49:43.860 --> 00:49:48.100 something of a consensus effort. And then using block times is sort of 00:49:48.100 --> 00:49:53.380 frustrating that in his opinion. I don't want to speak for him, but if 00:49:53.380 --> 00:49:59.380 I'm trying to sort of... channel Luke a little bit or trying to explain his 00:49:59.380 --> 00:50:03.080 perspective that would sort of be it. That in his view consensus was already 00:50:03.080 --> 00:50:06.400 forming and now a different path is taken. 00:50:06.400 --> 00:50:12.040 I don't think this new approach blocks any of the LOT=true stuff that much we 00:50:12.040 --> 00:50:17.260 looked through all the scenarios here and I don't think we got… the confusion 00:50:17.260 --> 00:50:20.740 wasn't around block height versus time right it was against all sorts of things 00:50:20.740 --> 00:50:25.680 that could go wrong depending on how things evolve, but not that particular 00:50:25.680 --> 00:50:31.020 issue. So I don't think you should worry about that. As for consensus, I mean, 00:50:31.080 --> 00:50:35.960 consensus is in the eye of the beholder, right? But I would say if multiple 00:50:35.960 --> 00:50:38.320 people disagree, then there's not consensus. 00:50:39.460 --> 00:50:44.020 Yeah, but that would also work the other way around, where Luke disagrees with 00:50:44.020 --> 00:50:45.500 using block time. 00:50:46.160 --> 00:50:50.560 Right, but then he cannot say there was consensus on something. People, if they 00:50:50.560 --> 00:50:52.680 disagree, then by definition there wasn't consensus. 00:50:55.620 --> 00:50:56.620 But maybe... 00:50:56.620 --> 00:51:01.500 Yes, it was my impression that there was no consensus because people disagreed. 00:51:01.800 --> 00:51:02.120 Exactly. 00:51:02.500 --> 00:51:02.680 Okay. 00:51:04.400 --> 00:51:05.660 Lars… Sjors. 00:51:05.920 --> 00:51:06.340 Sjors. 00:51:07.400 --> 00:51:08.920 I'm starting to forget your name. 00:51:09.080 --> 00:51:09.540 That's all right. 00:51:09.560 --> 00:51:13.880 The podcast is taking too long. Sjors, we're dwelling a lot. Let's wrap it up. 00:51:14.160 --> 00:51:17.870 I’m going to… for our listeners that are confused and worried, I'm going to 00:51:17.870 --> 00:51:22.690 emphasize the next three months, Speedy Trial is going to run on both clients. If 00:51:22.690 --> 00:51:26.930 miners activate through Speedy Trial, we're going to have Taproot in November and 00:51:26.930 --> 00:51:31.710 everyone's going to be happy. And then we'll continue the soft fork discussion 00:51:31.710 --> 00:51:33.450 with the next soft fork. 00:51:33.970 --> 00:51:37.770 Exactly. We can have the same arguments all over again because we have learned 00:51:37.770 --> 00:51:41.190 absolutely nothing. All right. In that case, thank you for listening to the 00:51:41.190 --> 00:51:42.130 Van Wirdum Sjorsnado. 00:51:42.470 --> 00:51:42.990 There you go.