WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:00.530 --> 00:00:02.890 Before the show, a quick word from our sponsor. 00:00:11.180 --> 00:00:13.700 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:13.940 --> 00:00:14.180 Hello. 00:00:15.000 --> 00:00:16.720 Sjors, what is your pun of the week? 00:00:16.860 --> 00:00:20.580 Well, I actually asked you for a pun and then you said, cut, re-edit, we're going 00:00:20.580 --> 00:00:23.320 to do it again. So I don't have a pun this week. 00:00:23.560 --> 00:00:24.360 Puns are your thing. 00:00:24.760 --> 00:00:27.180 Yeah, we tried this LOT thing last time. 00:00:27.440 --> 00:00:30.800 Okay, Sjors, we're going to talk a lot this week. 00:00:31.140 --> 00:00:33.420 We're still going to get blocked for this. Okay. 00:00:33.480 --> 00:00:38.570 We talked a lot two weeks ago. Okay, so a LOT was the parameter we discussed two 00:00:38.570 --> 00:00:44.550 weeks ago. A LOT is true, a LOT is false, about Taproot activation. We're two 00:00:44.550 --> 00:00:49.770 weeks further in, and now it seems like the community is 00:00:49.770 --> 00:00:53.990 somewhat reaching consensus on an activation 00:00:53.990 --> 00:00:59.450 solution called Speedy Trial. And that's what we're going to 00:00:59.450 --> 00:01:00.630 discuss today. 00:01:00.890 --> 00:01:01.510 That's right. 00:01:02.350 --> 00:01:07.520 Should we begin with Speedy Trial? What is it? What is Speedy Trial? Sure. 00:01:07.820 --> 00:01:12.400 Yeah, I think that's probably a good idea to do. So with the proposals that we 00:01:12.400 --> 00:01:17.010 talked about last time for activating Taproot, basically, Bitcoin Core released 00:01:17.010 --> 00:01:22.950 some software maybe in April or something. And then I think the miners will start 00:01:22.950 --> 00:01:27.030 signaling using that software. And I think it's in August or something. And then 00:01:27.030 --> 00:01:30.570 they can signal for a year. And at the end of the year, the whole thing ends. 00:01:31.570 --> 00:01:35.910 That was a LOT true or false. And then the debate was on whether or not it should 00:01:35.910 --> 00:01:40.530 end with forced signaling or not. That's the true-false thing. 00:01:40.850 --> 00:01:44.890 Yeah, but the thing to keep in mind here is that the first signaling would be a 00:01:44.890 --> 00:01:48.150 while before that starts happening. So until that time, we really don't know, 00:01:48.370 --> 00:01:53.290 essentially. So what the Speedy Trial proposes is to say, well, rather than 00:01:53.290 --> 00:01:57.510 discussing whether or not it's going to be signaling and having lots of arguments 00:01:57.510 --> 00:02:02.030 about it, let's just try that really quickly. So instead, there would be a 00:02:02.030 --> 00:02:07.120 release... Maybe also around April, whatever. Of course, there's nobody in charge 00:02:07.120 --> 00:02:11.900 of actual timelines. And in that case, the signaling would start much earlier. 00:02:12.180 --> 00:02:16.460 I'm not entirely sure when, maybe in May or pretty early. And the signaling would 00:02:16.460 --> 00:02:20.280 only be for three months. And at the end of three months, it would just give up. 00:02:20.200 --> 00:02:21.580 And the nice thing… 00:02:20.660 --> 00:02:23.320 It would end on LOT false, basically. 00:02:23.930 --> 00:02:28.730 Yeah, it's the equivalent of LOT false or just how it used to be with soft forks. 00:02:28.890 --> 00:02:31.990 It signals, but only for a couple months. And then… 00:02:31.990 --> 00:02:36.050 If it isn't activated within these months by hash power, which is going to be 00:02:36.050 --> 00:02:41.230 probably 90% hash power, so it's going to require 90% hash power to activate 00:02:41.230 --> 00:02:46.030 Taproot. If that doesn't happen, then the proposal expires. And when it expires, 00:02:46.050 --> 00:02:51.050 we can continue our discussion on how to activate Taproot. Or if it activates… 00:02:51.050 --> 00:02:51.830 Then what happens? 00:02:52.430 --> 00:02:56.810 Yeah, so the thing is, because you still want to give miners enough time to 00:02:56.810 --> 00:03:01.970 really upgrade their software, the actual Taproot rules won't take effect until 00:03:01.970 --> 00:03:03.430 September or August. 00:03:03.730 --> 00:03:07.030 Miners and actual users, Bitcoin users. 00:03:07.250 --> 00:03:08.690 Yeah, you want to give everybody 00:03:08.480 --> 00:03:09.040 Yes. 00:03:08.690 --> 00:03:12.830 plenty of time to upgrade. So the idea is we would start the signaling actually 00:03:12.830 --> 00:03:17.910 very quickly, also because miners can basically signal even without installing 00:03:17.910 --> 00:03:23.580 the software. But then once the signal threshold has been reached, 00:03:23.800 --> 00:03:27.620 then the software is sort of set in stone. It's going to happen, at least if 00:03:27.620 --> 00:03:32.060 people run the full nodes. And then there's still some time for people to upgrade 00:03:32.060 --> 00:03:35.080 and for miners to really upgrade and run that new software rather than just 00:03:35.080 --> 00:03:35.660 signal for it. 00:03:36.120 --> 00:03:37.820 Yeah, so to recap… 00:03:37.280 --> 00:03:41.360 They could… they could run that software but they might not. And that's why it's 00:03:41.360 --> 00:03:42.900 sort of okay to release a bit early. 00:03:43.200 --> 00:03:46.260 But they should really be running the software if they're signaling, right? 00:03:46.220 --> 00:03:49.240 Well, they… they should… No, I think… 00:03:49.240 --> 00:03:50.280 Let's get into that later. 00:03:50.460 --> 00:03:51.300 We can get into that later. 00:03:51.440 --> 00:03:56.400 Okay, so for now, to recap really briefly, Speedy Trial means release the 00:03:56.400 --> 00:04:01.840 software fairly fast and quickly after it is released, start the signaling period 00:04:01.840 --> 00:04:07.100 for three months, which is then relatively short for a signaling period. See if 00:04:07.100 --> 00:04:12.840 90% of miners agree. If they do, Taproot activates six months after 00:04:12.840 --> 00:04:17.900 the initial release of the software, I think. If 90% of miners don't activate 00:04:17.900 --> 00:04:23.520 within three months, the proposal expires and we can continue the discussion on 00:04:23.520 --> 00:04:25.640 how to activate SegWit… Taproot. 00:04:25.900 --> 00:04:30.420 Then we're just basically back to where we were a few weeks ago, but with more data. 00:04:31.180 --> 00:04:36.900 Right, exactly. So I want to briefly touch on how we got here because 00:04:36.900 --> 00:04:42.400 we discussed the whole true-false LOT thing and there appeared to be a gridlock. 00:04:43.060 --> 00:04:48.500 And I think because some people definitely didn't want LOT true, some people 00:04:48.500 --> 00:04:53.220 definitely didn't want LOT false. And then a third proposal entered the mix, 00:04:53.220 --> 00:04:58.860 which was it was always sort of it wasn't brand new, but it 00:04:58.860 --> 00:05:04.080 wasn't a major part of the discussion which was a simple flag day. So a simple 00:05:04.080 --> 00:05:09.290 flag day would have meant that the Bitcoin Core code would have included a date 00:05:09.290 --> 00:05:14.190 in the future or block block height in the future at which point the 00:05:14.190 --> 00:05:20.450 Taproot upgrades would activate regardless of hash power up until that point. 00:05:21.070 --> 00:05:26.830 Yeah, which I find an even worse idea, but I don't know, you know, when when 00:05:26.830 --> 00:05:29.350 there's a lot of debate people start just proposing stuff. 00:05:29.350 --> 00:05:34.730 Well, I… I think the… the reason is that the reason that we reached this sort of 00:05:34.730 --> 00:05:40.390 gridlock situation where people feel very strongly about different ideas 00:05:40.390 --> 00:05:46.200 has a lot to do with what happened during the SegWit upgrade and we've 00:05:46.200 --> 00:05:51.780 discussed this before but people have very different ideas of what actually 00:05:51.780 --> 00:05:57.230 happened. Some people feel very strongly that users 00:05:57.230 --> 00:06:02.630 show their muscles, users claimed their sovereignty, users claims 00:06:02.630 --> 00:06:07.850 back the protocol, and they basically forced miners to activate 00:06:07.850 --> 00:06:13.090 the SegWit… the SegWit upgrade and it was a huge victory for Bitcoin users. 00:06:13.090 --> 00:06:18.690 And then other people feel very strongly that Bitcoin came near 00:06:18.690 --> 00:06:24.650 a complete disaster with a fractured network and people losing money, and a 00:06:24.650 --> 00:06:30.450 big mess. And so the first group of people really kind of likes doing a 00:06:30.450 --> 00:06:34.890 UASF again, or starting with false and switching to true or maybe just starting 00:06:34.890 --> 00:06:39.730 with true or something like that. And people think it was a big mess they kind of 00:06:39.730 --> 00:06:44.710 prefer to just use a flag day this time, you know nice and safe, in a way, just 00:06:44.710 --> 00:06:48.630 use a flag day, none of this miner signaling, so miners also can't be forced to 00:06:48.630 --> 00:06:53.220 signal and all of that. So these different views on what actually happened a 00:06:53.220 --> 00:06:57.640 couple years ago now means people can't really agree on a new activation 00:06:57.640 --> 00:07:03.480 proposal. So after a lot of discussion, all factions were 00:07:03.480 --> 00:07:09.420 sort of willing to settle on Speedy Trial even though no one really 00:07:09.420 --> 00:07:14.000 likes it, for a couple of reasons, which we'll also get into but you know, the 00:07:14.000 --> 00:07:19.980 UASF people they kind of they're kind of okay with Speedy Trial because it 00:07:19.980 --> 00:07:24.280 doesn't really get in the way of the UASF. If the Speedy Trial fails they'll 00:07:24.280 --> 00:07:28.820 still just do the UASF next year. The flag day people are sort of okay, because 00:07:28.820 --> 00:07:34.220 the three months doesn't allow for a big enough window to do the UASF probably. 00:07:34.460 --> 00:07:38.260 And the UASF people have said that, you know, that's too fast indeed. And let's 00:07:38.260 --> 00:07:39.340 do this trial anyways. 00:07:39.640 --> 00:07:44.540 That's also still the LOT is false… Let's just do soft forks the way we've done 00:07:44.540 --> 00:07:48.610 them before where they might just expire… A group of people that were quietly 00:07:48.610 --> 00:07:54.530 continuing to work on the actual code that could do that. So it's, you know, 00:07:54.710 --> 00:07:57.850 just from mailing lists and Twitter, it's even hard to gauge what's really going 00:07:57.850 --> 00:07:59.270 on. This is a very short timescale. 00:07:59.630 --> 00:08:03.450 Yeah, the LOT is false people, you know, this is basically LOT is false just on a 00:08:03.450 --> 00:08:07.210 shorter timescale. So everyone's sort of willing to settle on this, even though 00:08:07.210 --> 00:08:08.470 no one really likes it. 00:08:08.610 --> 00:08:12.030 Well, from the point of view that I'm seeing, I'm actually looking at the code 00:08:12.030 --> 00:08:16.390 that's being written. And what I have noticed is that once a Speedy Trial 00:08:16.390 --> 00:08:20.440 proposal came out, more people came out of the woodworks and started writing code 00:08:20.440 --> 00:08:24.800 that could actually get this done. Whereas before, it was mostly Luke, I think, 00:08:24.900 --> 00:08:26.560 writing that one pull request. 00:08:27.140 --> 00:08:28.160 That's BIP 8, or? 00:08:28.850 --> 00:08:33.130 Yeah, BIP-8. So now, and I guess we can get into the technical details, but what 00:08:33.130 --> 00:08:36.550 I'm trying to say is that one thing that shows that the Speedy Trial seems like a 00:08:36.550 --> 00:08:40.330 good idea is that there's more developers from different angles cooperating on it 00:08:40.330 --> 00:08:43.210 and getting things done a little bit more quickly. When you have some 00:08:43.210 --> 00:08:47.770 disagreement, then people start procrastinating, not reviewing things or not 00:08:47.770 --> 00:08:51.890 writing things. So, but that's… that's kind of a vague indicator of this seems to 00:08:51.890 --> 00:08:56.190 be okay because people are working on it quickly and it's making progress so that's good. 00:08:56.630 --> 00:09:02.710 Right. Yeah, so some… some technical details I think you want to get into right? 00:09:02.710 --> 00:09:08.350 Yeah, so… so the idea of this Speedy Trial can be implemented in two different 00:09:08.350 --> 00:09:13.340 ways. You can use the existing BIP 9 system that we already have. 00:09:13.480 --> 00:09:13.840 Yes. 00:09:13.840 --> 00:09:17.240 And the argument for that would be, well, that's far less code because it already 00:09:17.240 --> 00:09:20.440 works and it's just for three months, so why not just use the old BIP 9 code? 00:09:20.760 --> 00:09:24.480 BIP 9 used date. A date into the future, right? 00:09:24.430 --> 00:09:28.700 Yeah, so you can tell when it… when the… when the signaling could start, when the 00:09:28.700 --> 00:09:34.460 signaling times out. And there's some annoying edge cases there where if it 00:09:34.460 --> 00:09:38.480 ends right around the deadline, but then there's a reorg and it ends right before 00:09:38.480 --> 00:09:41.840 the deadline, and then people's money might get lost if they try to get into the 00:09:41.840 --> 00:09:44.910 first Taproot block. And it's just difficult to explain. 00:09:45.150 --> 00:09:50.690 Because the thing is, the signaling happens per difficulty period of 2016 00:09:50.690 --> 00:09:56.510 blocks. And then at least up till now, 95% of blocks needed 00:09:56.510 --> 00:10:02.220 to signal support. But these two block periods… you know, they don't 00:10:02.220 --> 00:10:07.500 neatly fit into exact dates or anything. They just happen. But while the 00:10:07.500 --> 00:10:12.820 signaling period does start and end on specific dates, so then that's why you can 00:10:12.820 --> 00:10:14.260 get weird edge cases. 00:10:14.380 --> 00:10:17.520 Yeah, so let's do a little example there because it's kind of fun to illustrate. 00:10:18.000 --> 00:10:23.440 Let's say the deadline of this soft fork is on September 00:10:23.440 --> 00:10:29.390 1st. Pick a date for signaling. On September 1st at midnight UTC. Now, 00:10:29.710 --> 00:10:33.090 a miner mines block number, what was it? 00:10:34.310 --> 00:10:34.950 2016. 00:10:36.300 --> 00:10:41.920 You know, some multiple of 2016, because that's when the voting ends. And they 00:10:41.920 --> 00:10:47.380 mine this block one second before midnight UTC. And they signal 00:10:47.380 --> 00:10:53.260 yes. And so everybody who sees that block says, okay, we have 95% or whatever it 00:10:53.260 --> 00:10:58.520 is right before midnight. Taproot is active. And so they have this automatic 00:10:58.520 --> 00:11:02.040 script that says, I'm going to now put all my savings in a Taproot address 00:11:02.040 --> 00:11:05.680 because I want to be in the first block and I'm feeling reckless and I love being 00:11:05.680 --> 00:11:11.600 reckless. And then there is a, you know, another miner who mines 00:11:11.600 --> 00:11:15.500 two seconds later because they didn't see that, you know, recent block because, 00:11:15.620 --> 00:11:20.840 you know, that can be stale blocks. And they, their block arrives at one second 00:11:20.840 --> 00:11:21.640 past midnight. 00:11:23.070 --> 00:11:29.010 And it votes positive too, but it's too late. And so the software does 00:11:29.010 --> 00:11:32.910 not activate because the signaling was not done before midnight at the deadline. 00:11:33.510 --> 00:11:37.050 That's the subtlety you get with BIP 9. And, you know, usually it's not a 00:11:37.050 --> 00:11:40.510 problem, but it's difficult to explain these edge cases to people. 00:11:40.940 --> 00:11:46.480 And it gets a bigger problem, I'd say, maybe with shorter signaling 00:11:46.480 --> 00:11:47.540 periods as well. 00:11:47.740 --> 00:11:51.000 Yeah. Yeah, of course. If there's a longer signaling period, it's less likely 00:11:51.000 --> 00:11:54.100 that the signal is going to arrive just at the edge of a period. 00:11:54.680 --> 00:11:58.760 Yeah. About the threshold, is that still going to be... Because I thought it was 00:11:58.760 --> 00:12:00.760 going to be 90% this time, or is it... 00:12:00.760 --> 00:12:04.500 Well, so that's a separate thing. So first, let's talk about, regardless of the 00:12:04.500 --> 00:12:05.960 threshold, there's two mechanisms. 00:12:06.240 --> 00:12:06.680 Okay, sure. 00:12:06.760 --> 00:12:11.170 So one is based on time. That's BIP 9. You know, easy because we already have the 00:12:11.170 --> 00:12:13.930 code for it. Downside is all these weird things that you need to explain to 00:12:13.930 --> 00:12:17.330 people. And, you know, nowadays soft forks in Bitcoin are so important that maybe 00:12:17.330 --> 00:12:20.950 CNN wants to write about it. And it's nice if you can actually explain it without 00:12:20.950 --> 00:12:25.270 sounding like a complete nerd. But the alternative is to say, okay, let's just 00:12:25.270 --> 00:12:31.150 use this new BIP 8 that was proposed anyway, and that uses height. And we 00:12:31.150 --> 00:12:35.130 ignore all the LOT is true stuff, but the height stuff is very useful. And then 00:12:35.130 --> 00:12:39.560 it's much simpler. We're just saying, as of this block height, that's when the 00:12:39.560 --> 00:12:43.720 signaling ends. And that height is always at the edge of these retargeting 00:12:43.720 --> 00:12:47.280 periods. And so that's just easier to reason about. It's just saying, okay, if 00:12:47.280 --> 00:12:52.800 the signaling is achieved by a block, I don't know, [unclear] 700,321, then 00:12:52.800 --> 00:12:57.100 it happens or it doesn't happen. And even if there's a reorg, that could still be 00:12:57.100 --> 00:13:01.020 a problem, by the way, because there could be a reorg at the same height. But 00:13:01.020 --> 00:13:05.800 then the difference would be that it would activate because we just made the 00:13:05.800 --> 00:13:11.640 precisely 95%. And then there's a reorg and that miner votes no. And then 00:13:11.640 --> 00:13:12.480 it doesn't activate. 00:13:13.690 --> 00:13:14.030 Right. 00:13:13.950 --> 00:13:14.570 So you still… 00:13:14.570 --> 00:13:15.410 But that's that was… 00:13:15.410 --> 00:13:16.450 Yeah, but I was still… 00:13:16.450 --> 00:13:22.050 That's also true with BIP 9. So it's just you removed one edge case. You have one 00:13:22.050 --> 00:13:24.170 edge case less, which is better. 00:13:24.070 --> 00:13:27.330 In BIP 9, you could have the same same scenario. Exactly one vote. If it's… if 00:13:27.330 --> 00:13:31.490 it's just at the edge one miner votes yes, one miner votes no. But the much 00:13:31.490 --> 00:13:35.410 bigger problem with BIP 9 is that if the time on the block is one second after 00:13:35.410 --> 00:13:39.340 midnight or before. This matters, even if they're way over the threshold. So they 00:13:39.340 --> 00:13:44.320 might have 99.999%, but that last block comes in too late. And so the entire 00:13:44.320 --> 00:13:49.920 period is disqualified. So then you might be like with an election, you're 00:13:49.920 --> 00:13:53.400 looking at all the votes and you're saying, okay, it's got 97% support. It's 00:13:53.400 --> 00:13:56.780 going to happen. And then that last block is just too late and it doesn't happen. 00:13:57.600 --> 00:14:01.360 So again, difficult to explain, but we don't have this problem with height-based 00:14:01.360 --> 00:14:01.800 activation. 00:14:02.310 --> 00:14:08.150 Yeah, so I guess the biggest disadvantage of using BIP 8 is that the code isn't, 00:14:08.250 --> 00:14:10.810 it's a bigger change as far as code comes. 00:14:11.070 --> 00:14:14.770 Yeah, but to be honest, I have actually looked at that code yesterday and wrote 00:14:14.770 --> 00:14:18.450 some tests for it. And Andrew Chow and Luke Dashjr have already implemented a lot 00:14:18.450 --> 00:14:22.570 of it. It's already been reviewed by people. It is actually not too bad. It looks 00:14:22.570 --> 00:14:27.030 like 50 lines of code. However, you know, if there's a bug in it, it's really, 00:14:27.130 --> 00:14:32.090 really bad. So just because it's only a few lines of code doesn't mean it might 00:14:32.090 --> 00:14:36.370 be safer to use something that already is out there. But I'm not terribly worried about it. 00:14:36.750 --> 00:14:40.410 Right. And then there's the hash power threshold. 00:14:40.870 --> 00:14:41.470 Yes. 00:14:41.770 --> 00:14:43.410 Is it 90 or 95? 00:14:43.690 --> 00:14:48.750 I think in the current proposal, so what's being implemented now in Bitcoin Core 00:14:48.750 --> 00:14:54.630 is the general mechanism. So it is saying for any software that you 00:14:54.630 --> 00:15:00.510 call Speedy Trial, you could, for example, use 90%. But for Taproot, 00:15:00.810 --> 00:15:05.490 the code that is for Taproot in Bitcoin Core just says it never activates. That's 00:15:05.490 --> 00:15:08.430 sort of the way you indicate the software is in the code, but it's not going to 00:15:08.430 --> 00:15:14.230 happen yet. And it stays never activates. And these numbers are arbitrary. So the 00:15:14.230 --> 00:15:20.050 code will support 70% or 95%, as long as it's not some imaginary number or 00:15:20.050 --> 00:15:21.310 more than 100%. 00:15:22.830 --> 00:15:28.250 It's worth pointing out that in the end, it's always 51% effectively because 00:15:28.250 --> 00:15:32.550 51% of miners can always decide to orphan non-signaling blocks. 00:15:33.170 --> 00:15:36.520 Yeah, and create a mess. But they could, yeah. 00:15:36.780 --> 00:15:41.600 Yeah, I'm just, you know, it's something to be aware of that miners can always do 00:15:41.600 --> 00:15:42.640 that if they would choose to. 00:15:42.840 --> 00:15:45.900 Yeah, but the general principle that's being built now is that at least we could 00:15:45.900 --> 00:15:49.680 do a slightly lower threshold. And that might be still some discussion of whether 00:15:49.680 --> 00:15:53.340 or not that's safe or not. And then the final detail. 00:15:53.540 --> 00:15:57.040 But hang on, it's not settled yet, 90 or 95, as far as you know? 00:15:57.240 --> 00:15:58.200 I don't think so. 00:15:58.480 --> 00:15:58.680 Okay. 00:16:00.150 --> 00:16:03.270 But, you know, you can have some arguments in favor for it, because, but we'll 00:16:03.270 --> 00:16:07.820 get into that with the risk section. And the other thing, the final thing that's… 00:16:07.820 --> 00:16:11.800 Well, we can mention real briefly that the benefit of having a higher threshold 00:16:11.800 --> 00:16:15.880 is that a lower risk of orphan blocks after activation. 00:16:16.140 --> 00:16:16.400 Yes. 00:16:16.400 --> 00:16:17.680 That's mainly the reason. 00:16:17.860 --> 00:16:21.940 But because we are doing a delayed activation, so there's a long time between 00:16:21.940 --> 00:16:26.540 signaling and activation, whereas normally you signal and it immediately 00:16:26.540 --> 00:16:30.380 activates when the signaling, or at least within just two weeks, it activates. 00:16:30.700 --> 00:16:30.840 Yeah. 00:16:31.000 --> 00:16:36.210 But right now… it can take much, much longer. So that means you have a longer 00:16:36.210 --> 00:16:39.210 time to upgrade, so there's a little less risk of orphaning, even if you have a 00:16:39.210 --> 00:16:40.110 lower signaling threshold. 00:16:40.850 --> 00:16:44.450 True. Okay, and I think that was the first point you wanted to get at anyways, 00:16:44.650 --> 00:16:46.350 right? The delayed activation. 00:16:46.610 --> 00:16:50.850 Yeah, so what happens normally is you tally the votes in the last difficulty 00:16:50.850 --> 00:16:55.730 period, if it's more than whatever the threshold is, then the state of the 00:16:55.730 --> 00:17:01.150 software goes from started, as in we know about it, we're counting, to locked in. 00:17:01.650 --> 00:17:06.430 And the state locked in will normally last for two weeks or one retargeting 00:17:06.430 --> 00:17:12.420 period, and then the rules actually take effect. And what happens with 00:17:12.420 --> 00:17:16.880 Speedy Trial, the delayed activation part, is that this locked-in state will go 00:17:16.880 --> 00:17:22.020 on for much longer. It might go on for months. So it's locked in for months, and 00:17:22.020 --> 00:17:26.740 then the rules actually take effect. And this changes only two lines of code, so 00:17:26.740 --> 00:17:27.360 that's quite nice. 00:17:27.560 --> 00:17:32.930 Right. Okay. Should we get to some of the downsides of this proposal? 00:17:33.510 --> 00:17:37.910 Yeah, some of the risks. I think the first one we kind of briefly mentioned, 00:17:38.130 --> 00:17:44.030 because this thing is deployed quite quickly, and because it's very 00:17:44.030 --> 00:17:47.990 clear that the activation of the rules is delayed, there is an incentive for 00:17:47.990 --> 00:17:52.510 miners to just signal rather than actually install the code. And then they could 00:17:52.510 --> 00:17:56.670 procrastinate on actually installing the software. And that's fine unless they 00:17:56.670 --> 00:18:00.210 procrastinate so long that they forget to actually enforce the rules. 00:18:00.490 --> 00:18:04.150 Yeah, which sounds quite bad to me, Sjors. 00:18:04.920 --> 00:18:10.330 Yeah, but yeah, that is bad. I agree. Of course, it's always possible for miners 00:18:10.330 --> 00:18:14.230 to just signal and not actually enforce the rules, right? This risk exists with 00:18:14.230 --> 00:18:15.150 any software deployment. 00:18:15.770 --> 00:18:20.090 Yes, miners can always just signal, fake signal, and that has happened in the 00:18:20.090 --> 00:18:25.930 past. We've seen fake signaling. It was the BIP66 soft fork where we 00:18:25.930 --> 00:18:31.190 learned later that miners were fake signaling, in fact, because we saw big reorgs 00:18:31.190 --> 00:18:35.180 on the network. So that is definitely something we would want to avoid. 00:18:35.680 --> 00:18:38.600 Yeah, and I think we briefly explained this earlier, but we [unclear] explain it 00:18:38.600 --> 00:18:43.760 again. Bitcoin Core, if you use that to create your blocks as a miner, there are 00:18:43.760 --> 00:18:47.460 some safety mechanisms in place to make sure that you do not create a block that 00:18:47.460 --> 00:18:51.920 is invalid. However, if another miner creates a block that is invalid, 00:18:52.650 --> 00:18:56.970 you will mine on top of it. And then you have a problem because the full nodes 00:18:56.970 --> 00:19:02.110 that are enforcing Taproot will reject your block. And presumably most of the 00:19:02.110 --> 00:19:06.410 ecosystem, if this signaling thing works, will upgrade. But then you get into 00:19:06.410 --> 00:19:11.270 this whole very scary situation where you really hope that that's true. And that 00:19:11.270 --> 00:19:16.190 not a massive part of the economy is too lazy to upgrade and you get a complete mess. 00:19:17.200 --> 00:19:18.380 Yes, correct. 00:19:18.300 --> 00:19:23.900 I think that the term we used… we talked about is the idea of a troll, basically, 00:19:23.900 --> 00:19:29.680 a troll. So you could have a troll user. Let's say I'm a mean 00:19:29.680 --> 00:19:34.600 user and I'm going to create a transaction that looks like a Taproot transaction, 00:19:34.640 --> 00:19:38.580 but it is actually invalid according to Taproot rules. Now, the way that works, 00:19:38.800 --> 00:19:43.340 like the mechanism in Bitcoin to do soft forks, is that you have this version 00:19:43.340 --> 00:19:47.500 number in your SegWit transaction. And so you say this is a SegWit version 1 00:19:47.500 --> 00:19:53.340 transaction. And nodes know that you're allowed to, when you see a SegWit 00:19:53.340 --> 00:19:55.780 version you don't know about, a higher version than you know about… 00:19:55.900 --> 00:19:56.820 Or Taproot version. 00:19:57.340 --> 00:19:58.600 Well, a SegWit version. 00:19:58.900 --> 00:20:00.140 Oh, okay. Sure. Yeah. 00:20:00.340 --> 00:20:04.300 So current version of SegWit is version zero because we're nerds. And if you see 00:20:04.300 --> 00:20:08.740 a SegWit version transaction with one or higher, you assume that anybody can 00:20:08.740 --> 00:20:13.300 spend that money. That means that if somebody is spending from that address, you 00:20:13.300 --> 00:20:18.590 don't care. You don't consider the block invalid as an old node. But a node that 00:20:18.590 --> 00:20:23.390 is aware of the version will check the rules. So what you could do as a troll is 00:20:23.390 --> 00:20:27.090 you could create a broken Schnorr signature, for example. You just take your 00:20:27.090 --> 00:20:31.910 Schnorr signature and you swap one byte. Then if that is seen by an old node, it 00:20:31.910 --> 00:20:35.910 says, oh, this is SegWit version 1. I don't know what that is. It's fine. Anybody 00:20:35.910 --> 00:20:39.170 can spend this, so I'm not going to check the signature. But the Taproot nodes 00:20:39.170 --> 00:20:42.250 will say, hey, wait a minute, that's an invalid signature. Therefore, that's an 00:20:42.250 --> 00:20:46.750 invalid block. And we have a problem. Now, there's a protection mechanism there 00:20:46.750 --> 00:20:52.470 that normal miners will not mine SegWit transactions that they don't know 00:20:52.470 --> 00:20:56.590 about. So they will not mine SegWit version one if they're not upgraded. 00:20:57.270 --> 00:21:03.050 Isn't it also the case that regular nodes will just not forward the transaction 00:21:03.050 --> 00:21:03.710 to other nodes? 00:21:03.930 --> 00:21:05.150 That's another safety mechanism. 00:21:05.250 --> 00:21:06.650 Right, so there are two safety mechanisms. 00:21:07.110 --> 00:21:10.390 They're basically saying, hey, dear other node, I don't think you want to just 00:21:10.390 --> 00:21:14.330 give your money away. Or alternatively, you're trying to do something super 00:21:14.330 --> 00:21:18.320 sophisticated that I don't understand. There's something called standardness. If 00:21:18.320 --> 00:21:21.840 you're doing something that is not standard, I'm not going to relay it. But that 00:21:21.840 --> 00:21:27.400 is not a consensus rule. And that's important. It means that you can compile your 00:21:27.400 --> 00:21:31.400 node to relay those things. And you can compile your miner to mine these things. 00:21:31.980 --> 00:21:36.720 But it's like, you know, it's a footgun if you don't know what you're doing. But 00:21:36.720 --> 00:21:41.450 it's not against consensus. However, when a transaction is in a block… then you 00:21:41.450 --> 00:21:45.470 are dealing with consensus rules. And that, again, means that old nodes will look 00:21:45.470 --> 00:21:48.710 at it and say, I don't care. I'm not going to check the signature because that's 00:21:48.710 --> 00:21:52.430 a higher version than I know about. But the nodes that are upgraded will say, 00:21:52.530 --> 00:21:55.350 hey, wait a minute. This block contains a transaction that's invalid. This block 00:21:55.350 --> 00:22:00.780 is invalid. And so a troll user doesn't really stand a chance to do much damage. 00:22:00.980 --> 00:22:04.860 No, because the transaction won't make it over the peer-to-peer network. And even 00:22:04.860 --> 00:22:10.730 if it does, it would… only make it to miners that will still reject it. So 00:22:10.730 --> 00:22:13.190 troll user probably can't do much harm. 00:22:13.330 --> 00:22:17.510 So our troll example of a user that swaps one byte in a Schnorr signature, he 00:22:17.510 --> 00:22:20.790 tries to send this transaction, he sends it to a node that is upgraded. That node 00:22:20.790 --> 00:22:24.150 will say, that's invalid, go away, I'm going to ban you now. Or maybe not ban, 00:22:24.230 --> 00:22:29.360 but definitely gets angry. But if he sends it to a node that is not upgraded, 00:22:29.400 --> 00:22:33.520 that node will say, I don't know about this whole new SegWit version of yours. Go 00:22:33.520 --> 00:22:37.180 away. Don't send me this modern stuff. I'm like really old school. Send me old 00:22:37.180 --> 00:22:40.840 stuff. And so the transaction doesn't go anywhere, but maybe somehow it does end 00:22:40.840 --> 00:22:44.360 up with a miner. Then the miner says, well, I'm not going to mine this thing that 00:22:44.360 --> 00:22:48.600 I don't know about. That's dangerous because I might lose all my money. However, 00:22:49.020 --> 00:22:54.920 you may have a troll miner. Now that would be very, very expensive trolling. But, 00:22:55.080 --> 00:22:59.520 you know, we have billionaires in this ecosystem. So if you mine a block that is 00:22:59.520 --> 00:23:03.880 invalid, it's going to cost you a few hundred thousand euros, I think, at the 00:23:03.880 --> 00:23:05.120 current prices, maybe even more. 00:23:06.040 --> 00:23:07.920 Yeah, 300,000 something. 00:23:08.420 --> 00:23:13.860 Yeah. But if you have 300,000 euros to burn, you could make a block like that and 00:23:13.860 --> 00:23:17.840 just challenge the ecosystem and say, hey, here's a block. Let me see if you 00:23:17.840 --> 00:23:23.720 actually verify it. Then if you're a miner… So then if that block goes to 00:23:23.720 --> 00:23:27.620 nodes that are upgraded, those will reject it. If that block goes to nodes that 00:23:27.620 --> 00:23:33.180 are not upgraded... It's fine. It's accepted. But then if somebody mines on top 00:23:33.180 --> 00:23:38.220 of it, if that miner has not upgraded, they will not check it. They will build on 00:23:38.220 --> 00:23:43.140 top of it. And then eventually the ecosystem will probably reject that entire 00:23:43.140 --> 00:23:48.260 chain and it becomes a mess. So then you really, really, really want a very large 00:23:48.260 --> 00:23:52.420 majority of miners to really check the blocks, not just mine blindly in general. 00:23:52.600 --> 00:23:55.860 And there are already problems with miners just blindly mining on top of other 00:23:55.860 --> 00:23:58.080 miners, even for a few seconds. 00:23:59.750 --> 00:24:01.430 For like economic reasons. 00:24:02.090 --> 00:24:07.630 Yeah, so that was a long tangent on the problems with false signaling. 00:24:08.450 --> 00:24:08.970 Yes. 00:24:09.170 --> 00:24:12.290 Because all of this would only happen if miners are false signaling. 00:24:12.670 --> 00:24:17.030 Yeah, and false signaling, to be clear, it's not some malicious act. It's just a 00:24:17.280 --> 00:24:20.920 lazy convenient thing, you say, yeah yeah yeah don't worry I'll do my homework, 00:24:20.920 --> 00:24:24.220 you know, I'll I'll send you that memo in time. Don't worry. 00:24:24.220 --> 00:24:27.460 Yeah, I haven't upgraded yet, but I will upgrade, and you [unclear] know the 00:24:27.460 --> 00:24:31.640 difference for now. So, yeah, yeah, that's yeah that's that's sort of the risk of 00:24:31.640 --> 00:24:32.540 uh, false signaling. 00:24:32.540 --> 00:24:35.680 Yeah, it could be deliberate too, but that would have to be a pretty large 00:24:35.680 --> 00:24:36.360 conspiracy then. 00:24:36.360 --> 00:24:42.260 Yeah, I guess one… one other sort of concern, one risk that has been mentioned, 00:24:42.260 --> 00:24:47.860 is that using LOT false in general, just 00:24:47.860 --> 00:24:53.640 could help users launch a UASF because they could 00:24:53.640 --> 00:24:58.960 run a UASF client with LOT true and then incentivize miners to 00:24:58.960 --> 00:25:04.280 signal like we just mentioned, and that would not only mean they would fork off 00:25:04.280 --> 00:25:09.120 to their own software themselves but basically activate the software for the 00:25:09.120 --> 00:25:14.860 entire economy. That's not a problem in itself, but some people, I think, 00:25:14.960 --> 00:25:20.960 consider it a problem if users are incentivized to try a UASF. Do you understand 00:25:20.960 --> 00:25:21.440 that problem? 00:25:21.360 --> 00:25:27.340 I guess if… if we go for this BIP 8 approach right, if we don't… if we switch 00:25:27.340 --> 00:25:31.100 to using block height rather than timestamps it is… 00:25:31.100 --> 00:25:33.700 Or flag high… or flag day. 00:25:34.950 --> 00:25:36.950 Well, the Speedy Trial doesn't use a flag day. 00:25:37.170 --> 00:25:42.680 I know. I'm saying that if you do a flag day you cannot do a 00:25:42.680 --> 00:25:46.180 UASF that triggers something else. 00:25:46.840 --> 00:25:50.280 Well, yeah. Well, you could maybe. Why not? 00:25:50.730 --> 00:25:51.870 What would you trigger? 00:25:52.430 --> 00:25:57.150 Well, you can basically run... There is a flag day out there, but you deploy 00:25:57.150 --> 00:25:59.750 software that requires signaling. That's what… 00:25:59.610 --> 00:26:02.450 Yes, that's what UASF people would be running. 00:26:02.710 --> 00:26:06.300 Yeah, they can run that anyway. Even if there's a flag day, they can decide to 00:26:06.300 --> 00:26:09.520 run a software that requires signaling, even though nobody will signal probably, 00:26:09.620 --> 00:26:10.140 but they could. 00:26:10.420 --> 00:26:16.340 Absolutely, but they cannot co-opt, to call it that… LOT false nodes if 00:26:16.340 --> 00:26:17.780 there's only a flag day out there. 00:26:17.780 --> 00:26:22.080 Yeah that's true. Yeah, so they they would require the signaling, but the LOT 00:26:22.080 --> 00:26:26.120 false nodes that are out there would be like… not even LOT false… like the flag 00:26:26.120 --> 00:26:30.220 day nodes that are out there would be like okay I don't know why you're not 00:26:30.220 --> 00:26:33.880 accepting these blocks, but there's no signal. There's nothing to activate. 00:26:33.880 --> 00:26:36.600 There's just my flag day, and I'm gonna wait for my flag day. 00:26:36.600 --> 00:26:41.280 Yes, and I don't want to get into the weeds too much, but if there are no LOT 00:26:41.280 --> 00:26:47.110 false nodes to co-opt, then miners could just 00:26:47.110 --> 00:26:53.050 false signal. So now the UASF nodes are 00:26:53.050 --> 00:26:58.630