WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.050 --> 00:00:22.370 Live from Utrecht, this is Bitcoin. 00:00:22.950 --> 00:00:23.470 Explained. 00:00:23.690 --> 00:00:28.830 I love it. Here we are again. It feels very retro. 00:00:29.230 --> 00:00:33.750 We just recorded three quarters of an episode before you realized you weren't 00:00:33.750 --> 00:00:34.850 actually recording anything. 00:00:35.230 --> 00:00:39.710 Yep, there's this little device and you have to put the SD card in it. Otherwise, 00:00:39.970 --> 00:00:43.850 you'll press the record button and you'll see all the volume and all that stuff. 00:00:43.990 --> 00:00:45.770 It looks very good, but there is no counter. 00:00:46.290 --> 00:00:49.830 Yeah, I think that used to happen almost every time in the first couple of months. 00:00:49.990 --> 00:00:52.630 No, I think we've only done it once. 00:00:52.810 --> 00:00:57.330 No, [unclear] done it. What? No, we did it all the time, Sjors. 00:00:57.630 --> 00:00:57.810 Oh. 00:00:57.990 --> 00:00:58.790 Did you forget about that? 00:00:58.870 --> 00:00:59.990 Maybe I suppressed the memory. 00:01:00.910 --> 00:01:05.590 Anyways, so this time I hope you're recording and we're going to go for take two. 00:01:05.890 --> 00:01:07.850 I see a clock ticking, so that's good. 00:01:08.310 --> 00:01:12.780 Nice. We're going to discuss burying soft forks. 00:01:13.360 --> 00:01:14.000 All right. 00:01:14.200 --> 00:01:18.400 Yeah, this is one of these topics that I sort of knew was a thing that was 00:01:18.400 --> 00:01:24.200 sometimes discussed by developers, but also based on the discussion 00:01:24.200 --> 00:01:28.440 that I was sort of you know eyeing on the Bitcoin development mailing list I 00:01:28.440 --> 00:01:32.820 could tell that it was kind of a niche not super important kind of big deal sort 00:01:32.820 --> 00:01:37.760 of thing. You know, only developers that are very far into the weeds kind of 00:01:37.760 --> 00:01:40.280 cared about. So I never really paid attention to it. 00:01:40.380 --> 00:01:44.900 But then we were desperate to find a new topic and I found it and you found it interesting. 00:01:45.120 --> 00:01:48.100 Yeah, I thought it was actually kind of interesting. It's one of these topics 00:01:48.100 --> 00:01:51.640 that, you know, it might be niche, but it still has some sort of broader 00:01:51.640 --> 00:01:57.140 implications about, you know, how do we think about Bitcoin or in a way... 00:01:57.580 --> 00:02:02.700 I've always found protocol changes the most interesting part of Bitcoin because 00:02:02.700 --> 00:02:08.650 it kind of gives you a very existential idea of what Bitcoin actually is. Like if 00:02:08.650 --> 00:02:12.950 it can change, then you can sort of think about, you know, what conditions can 00:02:12.950 --> 00:02:17.890 you change it then or what is Bitcoin then? You can get very philosophical about 00:02:17.890 --> 00:02:21.570 it if you want to, but I don't think we're really going to do that today, but we 00:02:21.570 --> 00:02:27.230 are going to discuss burying soft forks. So yeah, we have discussed Taproot and 00:02:27.230 --> 00:02:30.070 Taproot activation in multiple episodes so far. 00:02:30.230 --> 00:02:31.870 It's a five-episode epic story. 00:02:32.030 --> 00:02:37.190 It's like a miniseries within our podcast from start to finish. We sort of 00:02:37.190 --> 00:02:42.460 covered the whole Taproot activation saga. And in a way, this is a new entry in 00:02:42.460 --> 00:02:44.860 that miniseries. So I like it. 00:02:45.060 --> 00:02:45.460 That's right. 00:02:45.740 --> 00:02:49.640 Probably the last one. Probably this will be the last entry because at this 00:02:49.640 --> 00:02:53.800 point, we're going to discuss, you know, the soft fork happened, the activation 00:02:53.800 --> 00:02:56.500 happened. It all went great. 00:02:59.240 --> 00:03:04.950 And at this point, the question is sort of, how do we move forward from there? 00:03:04.950 --> 00:03:09.530 How do we now retroactively kind of deal with the activation code and with 00:03:09.530 --> 00:03:13.530 Taproot? And that's what burying soft forks is about. 00:03:13.770 --> 00:03:18.410 Yeah. So one analogy that can be used, although we'll get to the philosophical 00:03:18.410 --> 00:03:24.350 discussion about that, is that activation code is a scaffold. It's like when you 00:03:24.350 --> 00:03:26.970 have a, you know, when there's a soft fork, it's like building a new house. And 00:03:26.970 --> 00:03:30.090 when you're building a house, there's a scaffold next to it. And then the 00:03:30.090 --> 00:03:33.750 question is, what do you do with the scaffold when the house is done? And that's 00:03:33.750 --> 00:03:36.230 kind of what we're going to talk about. Can we just remove it somehow? 00:03:36.610 --> 00:03:41.790 Yeah. So this has happened before. Burying soft forks, it's not a completely new 00:03:41.790 --> 00:03:47.790 concept. It is being discussed again, at least sort of on GitHub, not really 00:03:47.790 --> 00:03:51.070 on the Bitcoin dev list this time, I think, because I guess Bitcoin Core 00:03:51.070 --> 00:03:54.970 developers have already sort of agreed that this is kind of the way to go. 00:03:55.190 --> 00:03:56.310 Well, it's still open, so. 00:03:57.590 --> 00:04:02.010 All right. So it is being discussed again, but it has happened before. So I'll 00:04:02.010 --> 00:04:06.870 just let you explain, Sjors, what does it mean? What is burying a soft fork? 00:04:07.070 --> 00:04:09.470 Well, I think you wanted to recap first what a soft fork is. 00:04:09.550 --> 00:04:13.570 Yeah, sure. Let's start with that. You're right. For those listeners that don't 00:04:13.570 --> 00:04:13.990 know that. 00:04:14.310 --> 00:04:19.110 It's also relevant to explain how the burying works. So a soft fork is a 00:04:19.110 --> 00:04:20.130 tightening of the rules. 00:04:21.400 --> 00:04:25.960 And intuitively, you might think, what? How do you get new features when you have 00:04:25.960 --> 00:04:29.060 less rules? Well, we've explained this in earlier episodes, but basically, 00:04:29.380 --> 00:04:32.020 Bitcoin has a lot of ways to throw away money. 00:04:33.220 --> 00:04:38.460 And so you can make all sorts of addresses, quote unquote, that you can send 00:04:38.460 --> 00:04:42.540 coins to. And then anybody can take the money from those addresses. And 00:04:42.540 --> 00:04:43.640 generally, you don't want to do that. 00:04:43.740 --> 00:04:47.140 You don't even need a signature. There's just no requirements. You can just take 00:04:47.140 --> 00:04:50.040 the money from these outputs or addresses. 00:04:50.540 --> 00:04:55.900 So what a soft fork does in practice, at least some soft forks do, is to say, 00:04:56.020 --> 00:04:59.860 well, there's now going to be slightly fewer ways to throw away your money. So if 00:04:59.860 --> 00:05:02.780 you make this specific type of transaction, we're now going to call that Taproot. 00:05:03.340 --> 00:05:06.920 And you can only spend that with a valid Schnorr signature, et cetera, et cetera. 00:05:07.060 --> 00:05:10.220 Whereas before the soft fork, you could just take those coins. 00:05:10.800 --> 00:05:10.920 Right. 00:05:11.440 --> 00:05:16.360 And this ties into the burying of the soft fork because it turns out that if you 00:05:16.360 --> 00:05:20.340 look back at the history of the blockchain and you see how many people have 00:05:20.340 --> 00:05:26.140 actually thrown away their money in the past in a way that would now be 00:05:26.140 --> 00:05:29.890 called Taproot, it turns out that's only happened once. So there's only one 00:05:29.890 --> 00:05:34.930 historical transaction that happens before Taproot activated, where somebody sent 00:05:34.930 --> 00:05:39.250 money to something that we now call a Taproot address. And more importantly, 00:05:39.570 --> 00:05:44.070 somebody else took that money. And that taking of the money would not be 00:05:44.070 --> 00:05:46.230 compliant with the modern Taproot rules. 00:05:46.590 --> 00:05:50.450 Yes. Well, actually, I'll have to correct you there a little bit. So actually, 00:05:50.450 --> 00:05:56.080 several people sent money to a Taproot address before Taproot was active. 00:05:56.320 --> 00:05:57.160 But only one took it. 00:05:57.400 --> 00:06:02.220 Yes, it's only been taken one time. Now, sending to such an address was always 00:06:02.220 --> 00:06:05.680 okay, of course, and it's still okay, and that was never a problem. It's a taken 00:06:05.680 --> 00:06:11.480 from that address that since Taproot is active, you cannot do that 00:06:11.480 --> 00:06:15.380 anymore. But before Taproot was active, you could just take that money. 00:06:15.620 --> 00:06:16.140 That's right. 00:06:16.540 --> 00:06:17.020 Okay. 00:06:17.320 --> 00:06:21.300 And so this presents an opportunity to look at the Bitcoin Core source code, 00:06:21.460 --> 00:06:27.440 which currently just says, wait, when you see the blockchain for the first time, 00:06:27.640 --> 00:06:30.600 you think the whole thing, you look at the signaling, and then after a while, 00:06:30.600 --> 00:06:34.500 you've seen that the speedy trial activated, and now you're going to apply the 00:06:34.500 --> 00:06:38.380 new rules to the new blocks. What you can do instead is say, don't worry about 00:06:38.380 --> 00:06:42.580 the signaling, just apply the Taproot rules from the Genesis block onwards, 00:06:42.760 --> 00:06:47.350 pretend that Taproot has always existed, with one exception. And that exception 00:06:47.350 --> 00:06:51.950 would be hardcoded in the source code saying, well, Taproot is always active 00:06:51.950 --> 00:06:53.370 except for this specific block. 00:06:53.630 --> 00:06:58.290 Yes, and that block would be the block that includes the transaction that I just 00:06:58.290 --> 00:07:02.670 mentioned that took these coins. They were sent to Brink, actually. 00:07:04.050 --> 00:07:08.590 There's a blog post. While we're discussing it, let me just mention that real 00:07:08.590 --> 00:07:14.190 quick. So it was actually taken by... or at least the Bitcoin developer named 00:07:14.190 --> 00:07:19.730 0xB10C. He sort of initiated, and then it was included by 00:07:19.730 --> 00:07:25.310 F2Pool, and it was sent. So these coins were 00:07:25.310 --> 00:07:26.970 sent to Brink at the time. 00:07:27.110 --> 00:07:27.850 Oh, that's very nice. 00:07:27.970 --> 00:07:32.550 Not very important in the context of the rest of this episode, but a little detail. 00:07:31.160 --> 00:07:36.110 No, and it turns out something like this has happened in the past with BIP 16 00:07:36.110 --> 00:07:41.910 that introduced, back in 2012, that introduced pay-to-script hash. There was 00:07:41.910 --> 00:07:45.710 also one exception block. So there has been, there is precedent of having an 00:07:45.710 --> 00:07:49.430 exception block in the Bitcoin source code in this way. So the Taproot would just 00:07:49.430 --> 00:07:50.950 have another exception block. 00:07:51.630 --> 00:07:53.490 So let me recap that real quick. 00:07:53.730 --> 00:07:57.590 Okay. And with SegWit, I just add is there is no exception necessary. 00:07:57.910 --> 00:07:58.070 Right. 00:07:58.150 --> 00:08:02.550 So SegWit rules can be applied from the Genesis block perfectly. There's no exception. 00:08:02.810 --> 00:08:07.290 Right. Yes. Okay. So if you currently run a Bitcoin Core 00:08:07.680 --> 00:08:09.040 node, 00:08:10.780 --> 00:08:14.480 Better yet, if you sync a Bitcoin Core node, so if you start from the Genesis 00:08:14.480 --> 00:08:18.840 block, you start from the very first block that was released by Satoshi, and then 00:08:18.840 --> 00:08:22.240 you go through the entire blockchain to verify every transaction in every block, 00:08:22.520 --> 00:08:27.780 then what your Bitcoin Core node is currently doing is, at some point, it will 00:08:27.780 --> 00:08:32.860 check if there is blockchain signaling going on, and then it sees that there is, 00:08:32.880 --> 00:08:36.380 in fact, blockchain signaling going on, and then from a certain block, it will 00:08:36.380 --> 00:08:40.550 start to enforce the Taproot rules. That's how a Bitcoin Core node right now 00:08:40.550 --> 00:08:44.590 works when it comes to Taproot. And then this proposal, which has been done with 00:08:44.590 --> 00:08:48.890 other soft forks before, is that it will actually start applying the Taproot 00:08:48.890 --> 00:08:54.370 rules from block zero, from the very beginning, with the exception 00:08:54.370 --> 00:08:59.310 for this one block that has an invalid spend in it under the Taproot rules, and 00:08:59.310 --> 00:09:04.670 we'll just ignore that. Right? This is the recap. This is how it would work. So 00:09:04.670 --> 00:09:10.580 what are the benefits of implementing this in Bitcoin Core? Why is it better 00:09:10.580 --> 00:09:11.940 to start from block zero? 00:09:12.240 --> 00:09:15.800 Yeah, so I think the first thing to say is that this is not a dramatic benefit 00:09:15.800 --> 00:09:20.000 that we're going to talk about. It's somewhat marginal. However, we're dealing 00:09:20.000 --> 00:09:25.300 with very critical code. So the less headache basically for developers, the more 00:09:25.300 --> 00:09:27.760 likely they spend their time finding real bugs. 00:09:29.040 --> 00:09:33.020 It basically, first of all, it makes the code a little bit simpler, but that's 00:09:33.020 --> 00:09:37.630 very marginal. So instead of saying, after this block, do X, it says... do X all 00:09:37.630 --> 00:09:39.030 the time, except for this block. 00:09:39.270 --> 00:09:39.650 Right. 00:09:40.590 --> 00:09:44.630 And the other side is that it makes testing the code easier. So Bitcoin Core 00:09:44.630 --> 00:09:50.910 itself has tests that are run in something called the regtest framework from regression. 00:09:52.990 --> 00:09:58.410 And what these tests do is they simulate a fresh blockchain. So with a fresh 00:09:58.410 --> 00:10:02.550 Genesis block or maybe the real Genesis block. And then they create very low 00:10:02.550 --> 00:10:05.890 difficulty blocks. So they very quickly can build a blockchain with 100 blocks or 00:10:05.890 --> 00:10:11.770 200 blocks on it. And then they can check all the rules, basically. So there's a 00:10:11.770 --> 00:10:16.270 test that says, okay, make sure that before Taproot activates, these rules apply 00:10:16.270 --> 00:10:20.970 and these blocks are still valid. And then after Taproot activates, the test 00:10:20.970 --> 00:10:25.190 might check that the Taproot rules are actually enforced. And so if you just 00:10:25.190 --> 00:10:29.570 pretend that Taproot has always been there, 1984 style, then 00:10:29.570 --> 00:10:34.210 basically the test can be simplified because you only need to test for the 00:10:34.210 --> 00:10:38.360 enforcement of Taproot rules. You don't have to test anymore for pre-activation 00:10:38.360 --> 00:10:41.480 scenarios. So that's basically a simplification there. 00:10:42.290 --> 00:10:46.970 Right. So you've now mentioned two benefits. One of them, it cleans up the actual 00:10:46.970 --> 00:10:52.820 code of the Bitcoin Core code base. And the other way is it simplifies 00:10:52.820 --> 00:10:56.520 tests that you might run because now there's less scenarios. 00:10:56.900 --> 00:11:01.680 Well, those tests are in the Bitcoin source code too. So yeah, there's fewer 00:11:01.680 --> 00:11:05.400 permutations to test, right? Especially if you add up multiple soft forks. Like, 00:11:05.520 --> 00:11:09.680 okay, we have to test before SegWit and then after SegWit, but before Taproot. 00:11:10.060 --> 00:11:11.140 Those kind of combinations. 00:11:11.480 --> 00:11:15.240 Okay, so I think we can actually summarize it as it just cleans up the code. It's 00:11:15.240 --> 00:11:20.490 a... code cleanup. And the idea is essentially that 00:11:21.070 --> 00:11:26.980 the soft fork activated so long ago that it doesn't 00:11:26.980 --> 00:11:29.040 really make a difference. Am I saying that right? 00:11:29.040 --> 00:11:32.060 Well, we'll get to that. I think there's a second part to the cleanup that I want 00:11:32.060 --> 00:11:37.970 to emphasize and then we can say that analogy. The second thing is 00:11:37.970 --> 00:11:42.850 now that we've said Taproot has always existed as in the 1984 example. 00:11:43.910 --> 00:11:49.690 We still have these signals that happened in blocks. And, well, there's no point 00:11:49.690 --> 00:11:52.610 in looking at those signals anymore because we've already said SegWit is always 00:11:52.610 --> 00:11:56.810 there or Taproot is always there. So why do we look at the signals? So the second 00:11:56.810 --> 00:12:00.950 cleanup would be to simply not check those signals anymore. So to remove the 00:12:00.950 --> 00:12:06.830 speedy trial, essentially, in this case. And that has, again, somewhat of a 00:12:06.830 --> 00:12:11.900 benefit for developers. What it allows developers to do is say, hey, we want to 00:12:11.900 --> 00:12:15.720 change the activation mechanism itself. Maybe we want to change the BIP9 system 00:12:15.720 --> 00:12:21.300 to something more like a BIP8 system. And then we can just change the 00:12:21.300 --> 00:12:26.120 code, basically. We don't have to copy the code and write a new piece of code. We 00:12:26.120 --> 00:12:30.560 can change it entirely because the code is no longer used for anything. So it's 00:12:30.560 --> 00:12:34.740 safer to just change it. Again, that's marginal, but it's still nice. 00:12:35.040 --> 00:12:39.930 Yeah, and it's also still code cleanup, right? That's the benefit, essentially. 00:12:40.900 --> 00:12:45.940 Yeah, so especially if you understand that BIP-8, at least the simple version of 00:12:45.940 --> 00:12:51.580 BIP-8 with LOT is false that we talked about, is essentially simpler than BIP-9. 00:12:51.780 --> 00:12:56.800 So yeah, you can actually maybe remove some code net, but I don't know. 00:12:56.920 --> 00:13:00.600 Well, that wasn't really the point I was getting at. I was just, in general, just 00:13:00.600 --> 00:13:04.720 not having to check for the activation signals for the specific soft fork. 00:13:05.200 --> 00:13:07.280 Yeah, it saves, again, a little bit of code. 00:13:07.560 --> 00:13:13.380 Yeah. So that makes a lot of sense to me. I 00:13:13.380 --> 00:13:17.380 can barely think of any downside to that. And that is sort of what you were 00:13:17.380 --> 00:13:22.000 getting at earlier. You mentioned scaffolds, right? I think that was in this 00:13:22.000 --> 00:13:24.200 recording, not in the one we erased. 00:13:24.460 --> 00:13:25.740 Yeah, we brought it up in this recording. 00:13:25.980 --> 00:13:31.370 Or maybe in both. Anyway, so for the second benefit, you're basically removing 00:13:31.370 --> 00:13:35.930 the scaffolds. It activated. Everyone agreed that it activated on this specific block. 00:13:36.590 --> 00:13:41.530 Yeah, arguably both are scaffolds because the idea that you're going to start 00:13:41.530 --> 00:13:45.730 applying rules from a certain block is also a scaffold compared to just applying 00:13:45.730 --> 00:13:46.470 the rules all the time. 00:13:46.730 --> 00:13:52.430 Well, I think that's where the discussion comes in. So I 00:13:52.430 --> 00:13:58.130 think we're ready to point out where some of the disagreement stems from, right? 00:13:58.330 --> 00:13:58.730 Yep, we're ready. 00:13:58.990 --> 00:14:04.760 Right, so we've just mentioned that the main benefits are all kind of... 00:14:04.610 --> 00:14:10.270 code cleanup related. They benefit, you could argue, they benefit developers. You 00:14:10.270 --> 00:14:14.190 know indirectly anything that benefits developers benefits users because 00:14:14.190 --> 00:14:19.270 developers work for users, but they are things that benefit developers and they 00:14:19.270 --> 00:14:24.320 shouldn't affect users, and they arguably don't affect users. 00:14:24.390 --> 00:14:30.180 But there are some edge cases 00:14:30.180 --> 00:14:34.650 where it could actually affect users. So when we were discussing 00:14:34.650 --> 00:14:39.930 at the beginning of the episode, I think that was this one and not the one we 00:14:39.930 --> 00:14:45.850 erased. I hope we mentioned, anyways, that a soft fork can in fact 00:14:45.850 --> 00:14:48.990 split the blockchain or even a hard fork? 00:14:49.330 --> 00:14:51.350 No, I don't think we've said that in this recording yet. 00:14:51.670 --> 00:14:55.390 Okay, maybe do you want to point it out? Well, I'll just point it out. So 00:14:55.390 --> 00:15:00.970 basically, either a soft fork or a hard fork can split the 00:15:00.970 --> 00:15:05.890 blockchain between users that are using the old rules and users that are using 00:15:05.890 --> 00:15:11.240 the new rules. Great benefit of soft fork is that if a majority of hash power 00:15:11.240 --> 00:15:16.640 is enforcing the soft fork rules, then the chain should not split. Then 00:15:16.640 --> 00:15:20.740 the upgrade should be backwards compatible, as they call it. 00:15:21.950 --> 00:15:26.790 Which means that people do not have to upgrade their nodes immediately when 00:15:26.790 --> 00:15:29.190 there's a soft fork, and that's kind of nice. Because we don't want to force 00:15:29.190 --> 00:15:29.810 people to upgrade. 00:15:30.130 --> 00:15:35.060 Yeah, they can upgrade a bit later if they want, or potentially even never. Okay. 00:15:37.070 --> 00:15:42.970 In this case, a new Bitcoin Core node would assume that 00:15:42.970 --> 00:15:48.770 the Taproot rules have always applied. Now, what this means is that, 00:15:49.050 --> 00:15:55.050 and this is the edge case, if there is a very big reorg, so 00:15:55.050 --> 00:16:00.330 someone starts mining on top of a block from a year ago or whatever it is, 00:16:00.490 --> 00:16:06.450 and... That someone, you know, aliens have come to Earth, I think is the analogy. 00:16:07.050 --> 00:16:12.880 Yeah, it's either the aliens or some secret government 00:16:12.880 --> 00:16:13.320 agency. 00:16:13.580 --> 00:16:17.920 Yeah, someone has a lot of hash power for whatever reason. They start mining on a 00:16:17.920 --> 00:16:23.640 block from a year ago, and they actually claim the longest chain. Now, in that 00:16:23.640 --> 00:16:28.430 chain, they make a transaction. 00:16:29.730 --> 00:16:35.230 And they do this before the original Taproot activation block. They make a 00:16:35.230 --> 00:16:37.170 transaction that breaks the Taproot rules. 00:16:37.510 --> 00:16:37.850 That's right. 00:16:38.070 --> 00:16:43.670 So all nodes, all Bitcoin Core nodes, for example, will accept this chain because 00:16:43.670 --> 00:16:49.250 it's the longest valid chain. While new Bitcoin Core nodes who are enforcing all 00:16:49.250 --> 00:16:53.430 their Taproot rules, no, sorry, who are enforcing Taproot rules from the 00:16:53.430 --> 00:16:58.480 beginning, they will reject this chain because... It's an invalid chain. 00:16:58.680 --> 00:17:03.120 Yeah, so basically when a new chain appears, what the node will do is it will 00:17:03.120 --> 00:17:07.940 just roll back its blockchain. It will just basically do everything in reverse. 00:17:08.200 --> 00:17:12.780 And when all the coins that are spent are recreated until it gets to the forking 00:17:12.780 --> 00:17:16.820 point and then follows the longest chain all the way up, checking the rules for 00:17:16.820 --> 00:17:21.220 that new longest chain. And so if it goes, indeed, if it goes before Taproot 00:17:21.220 --> 00:17:27.010 activation, then... yeah, Taproot rules didn't apply. If you're an old node, you 00:17:27.010 --> 00:17:30.210 would say, okay, Taproot is no longer active because you've gone back in time. 00:17:31.100 --> 00:17:35.920 And those blocks can just do whatever they want. But if you're a new node under 00:17:35.920 --> 00:17:39.930 this little cleanup, you're going to say... No, no, no. Taproot rules are always 00:17:39.930 --> 00:17:44.790 active. So if anything violates Taproot rules, I'm going to complain. So that 00:17:44.790 --> 00:17:48.930 means if the new blocks are written, you know, at the low enough, then yeah, it's 00:17:48.930 --> 00:17:49.370 going to be a problem. 00:17:49.830 --> 00:17:49.950 Yeah. 00:17:50.150 --> 00:17:53.870 And it could even be worse. Like Taproot could never activate at all, according 00:17:53.870 --> 00:17:57.550 to the old nodes. Because if you go back before the speedy trial, if the aliens 00:17:57.550 --> 00:18:02.890 basically reorg back to 2020, they then, and then replay again, they might just 00:18:02.890 --> 00:18:08.760 decide to not signal for Taproot and say Taproot never happened. Now, the 00:18:08.760 --> 00:18:13.260 reason we don't care about that this much is that this scenario is really, 00:18:13.360 --> 00:18:18.240 really, really bad. So the analogy might be to say, well, if all of the 00:18:18.240 --> 00:18:22.200 Netherlands is flooded, are we really going to argue about this street name in 00:18:22.200 --> 00:18:24.500 Rotterdam that we have issues about? 00:18:25.540 --> 00:18:30.680 Right, yes. The arguments, I'll just, you explain it clearly, I think, but still 00:18:30.680 --> 00:18:36.520 to reiterate, the argument is that if a... reorg happens that is 00:18:36.520 --> 00:18:42.340 this bad then Bitcoin is screwed either way and it's not worth considering 00:18:42.340 --> 00:18:45.060 even, essentially, right? Or 00:18:45.060 --> 00:18:49.640 maybe at least you probably have to do some human intervention to decide what, 00:18:49.640 --> 00:18:52.460 what on earth you're going to do about this situation because it means that 00:18:52.460 --> 00:18:56.240 probably lots of people's coins won't, won't exist anymore. 00:18:57.790 --> 00:19:03.290 Yeah, all the transactions may or may not be replayed again. So unless you bought 00:19:03.290 --> 00:19:06.750 Bitcoin in 2011 and you just HODLed and never moved them, you're going to be 00:19:06.750 --> 00:19:10.850 impacted by this event. And the whole point of a money system, you know, kind of 00:19:10.850 --> 00:19:16.520 goes away if that much changes. It's very similar to in a fiat system if 00:19:16.520 --> 00:19:20.020 suddenly your bank account is zero or a million, depending on some random 00:19:20.020 --> 00:19:24.600 historical glitch. Are you really going to just keep on going with the bank 00:19:24.600 --> 00:19:28.340 balance or are you going to do something else? It's a big disaster if this happens. 00:19:28.700 --> 00:19:32.900 Yeah, well, so on the other side of the debate is, for example, Eric Voskuil, 00:19:33.080 --> 00:19:38.420 who's the lead developer of Libbitcoin. And he argues, or at least one of his 00:19:38.420 --> 00:19:44.320 arguments is that this threshold that you just... like 00:19:44.320 --> 00:19:49.800 at what point is this the case? At what point doesn't it matter anymore that 00:19:49.800 --> 00:19:54.420 there's a big reorg? Like is it after a day? Is it after two days? Is it after a 00:19:54.420 --> 00:19:57.020 week, two weeks? Like where is this threshold? 00:19:57.340 --> 00:19:57.520 Yeah. 00:19:57.860 --> 00:20:03.750 And you know, he, I guess he values consistency a 00:20:03.750 --> 00:20:08.540 lot when it comes to these kinds of things. And his argument would be, or is, I 00:20:08.540 --> 00:20:13.500 think, well, I need to be careful to represent his arguments because he might 00:20:13.500 --> 00:20:16.340 disagree with my explanation of it. 00:20:16.360 --> 00:20:19.500 We could say a hypothetical argument could be whether or not somebody makes the argument. 00:20:19.820 --> 00:20:20.680 Maybe that's better. 00:20:22.220 --> 00:20:28.100 The only consistent argument there is there is no threshold. It's just for 00:20:28.100 --> 00:20:33.420 each block, you need to assign a probability that 00:20:33.420 --> 00:20:39.240 it... it's gonna make reorgs harder. So the more confirmations you have it will 00:20:39.240 --> 00:20:43.840 just make a reorg harder and harder and harder, and it's kind of how we apply it 00:20:43.840 --> 00:20:48.580 already. Like, you know, one confirmation is not as secure as two confirmation is 00:20:48.580 --> 00:20:54.440 not as secure as three and this change would imply that there's some hard 00:20:54.440 --> 00:21:00.310 cutoff to that logic rather than it's just always going to be incrementally safer 00:21:00.310 --> 00:21:01.050 to wait longer. 00:21:01.190 --> 00:21:05.730 Now, there is actually a real cutoff because very old versions of Bitcoin Core 00:21:05.730 --> 00:21:10.750 use checkpoints, but that hasn't been done for many, many years. But a checkpoint 00:21:10.750 --> 00:21:15.050 basically meant that that specific block had to exist. So there are a couple of 00:21:15.050 --> 00:21:18.050 blocks in the source code that say this block must exist, otherwise the chain is 00:21:18.050 --> 00:21:18.450 not valid. 00:21:18.730 --> 00:21:22.310 Yes, but that is itself also controversial. 00:21:22.590 --> 00:21:24.950 Yeah, and I think it's good that those don't exist anymore. 00:21:25.070 --> 00:21:25.610 Right, exactly. 00:21:25.850 --> 00:21:30.770 But this is not as strong as a checkpoint. The only thing you could argue, and I 00:21:30.770 --> 00:21:34.810 think maybe that's what Voskuil was arguing, is that the fact that you're now 00:21:34.810 --> 00:21:40.770 retroactively, in a certain sense, activating Taproot is... is in a way a hard fork. 00:21:41.680 --> 00:21:45.800 No, it is in a way a checkpoint. I mean, it's like... 00:21:45.800 --> 00:21:48.180 Well, a checkpoint says this specific block has to exist. 00:21:48.340 --> 00:21:48.520 Yes. 00:21:48.660 --> 00:21:52.000 This just says these rules have to apply, regardless of what the blocks are. 00:21:52.200 --> 00:21:56.860 No, sure, but it does have sort of the similar implications for it, because 00:21:56.860 --> 00:22:02.500 you're assuming that before that block, no split could have possibly happened. 00:22:03.020 --> 00:22:06.310 Otherwise, you would have to check, right? Am I saying that right? I think so. 00:22:06.430 --> 00:22:11.490 Well, I mean, the problem with checkpoints is you could have almost completely 00:22:11.490 --> 00:22:15.850 arbitrary rules, right? It gives too much power to the people who decide what is 00:22:15.850 --> 00:22:19.250 a checkpoint. But I think in the case of Taproot, you don't have that discussion 00:22:19.250 --> 00:22:24.170 because it's not that by having this rule or by not having this rule, that 00:22:24.170 --> 00:22:28.250 Taproot is always active. It doesn't really matter that much. It's like there's 00:22:28.250 --> 00:22:31.370 not a specific person who stands to benefit from whether or not that rule 00:22:31.370 --> 00:22:35.300 happens. We can't predict what the disaster is going to look like. So that's why 00:22:35.300 --> 00:22:36.920 I think it's not as bad as a checkpoint. 00:22:37.480 --> 00:22:42.120 So, yeah, whether or not it's a checkpoint or some kind of checkpoint or some 00:22:42.120 --> 00:22:45.760 kind of subcategory of a checkpoint is maybe not the important part. The 00:22:45.760 --> 00:22:49.040 important part here is that one 00:22:50.350 --> 00:22:54.750 group of developers, I guess mostly in Bitcoin Core, figure that if there's a 00:22:54.750 --> 00:22:59.990 reorg this big, then Bitcoin is screwed anyways. While someone like Voskuil will 00:22:59.990 --> 00:23:04.600 argue, you know, there's no single point where you can make that argument. 00:23:04.800 --> 00:23:10.220 There's no point where Bitcoin will be dead if the reorg is that bad. It just 00:23:10.220 --> 00:23:16.120 gets incrementally worse for every extra block that's being reorg. But 00:23:16.120 --> 00:23:20.060 there's no objective point you can point to. And therefore, the only sort of 00:23:20.060 --> 00:23:25.200 logic that you can apply is simply longest [unclear] chain. That's what will you 00:23:25.200 --> 00:23:27.240 accept to be Bitcoin. 00:23:27.600 --> 00:23:33.090 So this reminded me of the other argument that you can have here, which is, 00:23:33.290 --> 00:23:38.330 do we look at only the blockchain? Like should nodes only look at the blockchain 00:23:38.330 --> 00:23:42.690 or should nodes keep into account sort of the social consensus? And that gets 00:23:42.690 --> 00:23:47.870 back to what signaling means. Is signaling something that must occur on the 00:23:47.870 --> 00:23:53.090 blockchain and then a soft fork is active? Or is it a way to coordinate the 00:23:53.090 --> 00:23:58.930 activation of a new set of rules in a point in... And so in essence... does the 00:23:58.930 --> 00:24:04.470 soft fork activate on a chain or does it activate in a chronological point in the 00:24:04.470 --> 00:24:09.170 space-time continuum? So can we say, as of November 21, or whatever date it was, 00:24:09.330 --> 00:24:15.250 2021, Taproot is active. If you produce blocks in the future, no matter what the 00:24:15.250 --> 00:24:20.010 height of those new blocks is, it's still after November 21, 2022, and therefore 00:24:20.010 --> 00:24:22.570 you should know that Taproot is active and you should just enforce it. 00:24:23.800 --> 00:24:29.570 That is, of course, also a philosophical question you can have. And if you agree 00:24:29.570 --> 00:24:34.510 with the latter, if you say Taproot should be considered active after a 00:24:34.510 --> 00:24:39.720 chronological point in time, well, then this deep reorg is not a problem because 00:24:39.720 --> 00:24:40.920 you'll enforce Taproot. 00:24:44.620 --> 00:24:50.060 Well, I think there's two issues here, or at least there's one thing to point 00:24:50.060 --> 00:24:52.060 out, and I think that's what you're getting at. 00:24:53.780 --> 00:24:58.680 So there are sort of two... visions on what the activation logic is in the first 00:24:58.680 --> 00:25:04.020 place. So everyone agrees, you know, basically what a soft fork is and that's, 00:25:04.020 --> 00:25:08.920 you know, you've explained it a couple minutes ago, and I think everyone will 00:25:08.920 --> 00:25:13.960 agree on that, but then there's the activation of the soft fork sort of the 00:25:13.960 --> 00:25:19.460 activation logic, like you must signal or the signaling 00:25:19.460 --> 00:25:25.250 logic itself which is something some developers will itself consider a soft 00:25:25.250 --> 00:25:30.650 fork while other developers will argue that's the word you used before, is it? 00:25:30.650 --> 00:25:35.140 That's scaffolding that shouldn't be considered a consensus change. So I think 00:25:35.140 --> 00:25:40.300 that the arguments, at least if you hold the second opinion, of removing the 00:25:40.300 --> 00:25:44.950 signaling logic from the code that's a much easier argument to make which I also 00:25:44.950 --> 00:25:46.150 mentioned before, I think. 00:25:46.490 --> 00:25:50.590 Yeah, I mean, we presented these two parts of the burying, right? So the first 00:25:50.590 --> 00:25:53.310 part is we're going to apply the rules from Genesis and the second part is we 00:25:53.310 --> 00:25:57.810 don't check the rules. And in that order, that's one way to look at it in that 00:25:57.810 --> 00:26:00.510 order, but you can look at it in the other order. I guess that's what you're 00:26:00.510 --> 00:26:04.150 saying now if you just drop the signaling requirement. 00:26:05.060 --> 00:26:09.420 Yeah, but you were making a point about social consensus applying to time, but 00:26:09.420 --> 00:26:14.820 you can still apply social consensus to the blockchain itself. So you can still 00:26:14.820 --> 00:26:20.520 argue that there's no reason for the signaling other than informing people that a 00:26:20.520 --> 00:26:24.880 soft fork is happening while still applying it to the actual blockchain and 00:26:24.880 --> 00:26:30.850 therefore accepting that a soft fork didn't happen if there's a big reorg, even 00:26:30.850 --> 00:26:32.170 though we're past a certain date. 00:26:32.410 --> 00:26:36.790 You could, but if you go back to the history of soft forks, you know, we did that 00:26:36.790 --> 00:26:42.550 in another episode, but basically the reason miners started signaling, that 00:26:42.550 --> 00:26:46.050 wasn't the case. The earliest soft forks in Satoshi's code were just activating 00:26:46.050 --> 00:26:49.490 at a certain height. That was a problem. So the idea was to have miners signal 00:26:49.490 --> 00:26:52.650 for it, and there were various ways to do that signaling, and eventually we ended 00:26:52.650 --> 00:26:56.210 up with BIP 9. But the reason for the signaling is to make sure that miners 00:26:56.210 --> 00:26:59.910 actually upgrade and are actually ready. And there's no reason to assume that 00:26:59.910 --> 00:27:03.920 with a big reorg, they're suddenly unready. They would have to downgrade their 00:27:03.920 --> 00:27:04.700 software, basically. 00:27:06.880 --> 00:27:09.240 That's not something everyone agrees on, Sjors. 00:27:09.520 --> 00:27:12.820 That's fine. That's sort of the point I'm trying to make. If that is your 00:27:12.820 --> 00:27:18.700 interpretation, if the interpretation is we use the signaling in the actual 00:27:18.700 --> 00:27:23.360 history of Earth just to say, okay, now all the miners are ready. They have the 00:27:23.360 --> 00:27:27.810 latest software. They can enforce Taproot. Then there's no reason to assume that 00:27:27.810 --> 00:27:32.520 when there's a deep reorg, they're certainly unready. But you can also have the 00:27:32.520 --> 00:27:36.120 blockchain-centric perspective where you say, no, there is no reality outside the 00:27:36.120 --> 00:27:41.900 blockchain and outside this code. And in that case, you might say, no, if time is 00:27:41.900 --> 00:27:45.940 undone, it's like real time travel. We've really changed history and Taproot 00:27:45.940 --> 00:27:48.080 never happened or did or some other time. 00:27:50.520 --> 00:27:52.560 That is a potential discussion you can have. 00:27:52.640 --> 00:27:55.800 Yeah, well, that's interesting you bring that up. I think that's right. So these 00:27:55.800 --> 00:28:00.840 are sort of two ways of looking at signaling, whether it's informing... 00:28:01.600 --> 00:28:05.880 miners or really whether it really means readiness signaling which is definitely 00:28:05.880 --> 00:28:10.300 a term that has been used, but recently during the Taproot debates there was also 00:28:10.300 --> 00:28:15.540 sort of this idea that signaling is really for users, so users know that a 00:28:15.540 --> 00:28:21.220 certain change will activate which also allows them to fork off if they disagree 00:28:21.220 --> 00:28:25.460