WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.630 --> 00:00:23.770 Live from Utrecht, this is Bitcoin. Explained. Hey Sjors. 00:00:24.070 --> 00:00:24.590 What's up? 00:00:25.010 --> 00:00:26.250 How's life in the McDrive? 00:00:27.070 --> 00:00:30.670 Excellent. Well, it's the McWalk now, I guess, because, you know. 00:00:31.240 --> 00:00:32.780 You don't even have a car anymore. 00:00:32.840 --> 00:00:33.680 No, you work there, right? 00:00:34.000 --> 00:00:35.280 We both work there now. 00:00:35.500 --> 00:00:39.480 Oh, you mean life from the McDrive. 00:00:39.620 --> 00:00:43.560 Yeah, no, it's great. I actually used to work at McDonald's in my teenage years. 00:00:44.170 --> 00:00:44.570 Okay. 00:00:44.950 --> 00:00:45.730 It was kind of fun. 00:00:45.950 --> 00:00:48.930 I was more into newspaper delivery and that sort of stuff. 00:00:49.210 --> 00:00:51.010 Oh, yeah, sure. So I got a question. 00:00:51.390 --> 00:00:52.230 Great. Tell me. 00:00:52.330 --> 00:00:57.550 From one of our listeners. From Vinay Shetty. It's a question from a while ago, 00:00:57.630 --> 00:01:01.150 actually, but we're finally going to address it. Before we get into the actual 00:01:01.150 --> 00:01:06.470 episode. By the way, the actual episode is about James Lopp's hard fork research. 00:01:06.710 --> 00:01:10.170 So our listeners also know this now. But we're first going to address a quick 00:01:10.170 --> 00:01:13.210 question from one of our listeners, which is, Sjors, are you ready? 00:01:13.520 --> 00:01:14.120 I'm ready. 00:01:14.120 --> 00:01:20.040 So the tweet is curious on how the DNS seeders work when the 00:01:20.040 --> 00:01:26.000 node is set up as an onion node. I set up a prune node and all I had was dot 00:01:26.000 --> 00:01:30.880 onion outgoing connections. Am I querying the DNS seeders for that information? 00:01:30.880 --> 00:01:34.720 Or do I get that information from the hard-coded file? Sjors? 00:01:35.140 --> 00:01:37.980 Well, assuming this tweet was not written three years ago. 00:01:38.820 --> 00:01:40.560 It was written like two months ago. 00:01:40.740 --> 00:01:45.980 Okay. Because with Tor v2, it was a little bit different. But we had an episode 00:01:45.980 --> 00:01:50.680 where we explained the difference between Tor v2 and Tor v3. But with Tor v3, 00:01:50.800 --> 00:01:54.780 it's very safe to say that you did not get that from the DNS seeds. So what 00:01:54.780 --> 00:01:59.380 happens is when your node starts up... It will query the DNS seeds to see if 00:01:59.380 --> 00:02:00.420 there's other nodes out there. 00:02:01.680 --> 00:02:07.320 But if you configured your node to only connect to Tor nodes, then it won't find 00:02:07.320 --> 00:02:11.200 anything because the DNS seeds are not actually telling you where the Tor nodes 00:02:11.200 --> 00:02:15.920 are. It only knows where the IPv4 nodes are and where the IPv6 nodes are. So that 00:02:15.920 --> 00:02:20.760 means if you didn't run your node before, like ever, 00:02:21.080 --> 00:02:25.740 without Tor, then the only way you would have found those onion addresses that 00:02:25.740 --> 00:02:29.780 you connected to now is because you found one that was hard-coded in the source 00:02:29.780 --> 00:02:34.000 code. So basically, if the DNS seeds don't give you anything useful... Which 00:02:34.000 --> 00:02:36.980 would be the case, right? If you're asking them for Tor addresses, but you're 00:02:36.980 --> 00:02:41.900 only getting IPv4 and IPv6 addresses, then your node is going to fall back to 00:02:41.900 --> 00:02:47.080 some hard-coded Tor addresses that are in the source code. And if any of those 00:02:47.080 --> 00:02:51.960 still exist, it will connect to them, and then it will get a bunch of other Tor 00:02:51.960 --> 00:02:54.920 services from that first connection, and then you'll connect to those. 00:02:55.500 --> 00:03:00.570 Okay. Vinay, I hope that helps. Sjors, let's get into the main topic of this 00:03:00.570 --> 00:03:04.190 episode. All right. Oh, and if any other listeners, you know, if you have 00:03:04.190 --> 00:03:08.570 questions or if you have an idea for a topic we can discuss for an entire 00:03:08.570 --> 00:03:14.230 episode, feel free to let us know on Twitter. I'm at Aaron Van W. And Sjors is 00:03:14.230 --> 00:03:15.090 at provoost. 00:03:15.410 --> 00:03:18.390 That's right. And if you want the answer a bit quicker than three weeks, you 00:03:18.390 --> 00:03:20.250 should probably also ask Bitcoin Stack Exchange. 00:03:21.160 --> 00:03:26.920 All right, Sjors, on to the main topic. All right. So Jameson Lopp wrote another 00:03:26.920 --> 00:03:31.780 excellent blog post. We've discussed one of his blog posts before. I think that 00:03:31.780 --> 00:03:37.780 was Syncing Old Nodes, episode 55. Cool. I'm pretty sure it was 00:03:37.780 --> 00:03:43.180 55. I'm actually almost entirely sure it was 55. And this time he 00:03:43.180 --> 00:03:47.620 published a blog post called Has Bitcoin Ever Hard Forked? 00:03:49.170 --> 00:03:54.830 So it discusses whether Bitcoin has ever hard forked, 00:03:54.990 --> 00:04:00.990 obviously. Okay. First of all, I'll just ask you right now, what is 00:04:00.990 --> 00:04:01.430 a hard fork? 00:04:02.220 --> 00:04:06.480 Well, as Lopp actually points out in the blog post, it's a bit of an ambiguous 00:04:06.480 --> 00:04:10.680 term, but generally what we mean is it's a loosening of the rules. I mean, it's 00:04:10.680 --> 00:04:13.940 only a fork if something actually happens. Or at least that's what we could 00:04:13.940 --> 00:04:16.880 debate about. But generally, the difference between a hard fork and a soft fork 00:04:16.880 --> 00:04:20.780 is to say, in a hard fork, you're loosening the rules. So, for example, you might 00:04:20.780 --> 00:04:25.520 be allowing 2 megabyte blocks instead of 1 megabyte blocks. And a soft fork would 00:04:25.520 --> 00:04:28.700 be tightening the rules. So you might say, we're only going to allow smaller 00:04:28.700 --> 00:04:34.520 blocks. And this matters in terms of whether or not you need to upgrade very 00:04:34.520 --> 00:04:36.740 quickly to be able to follow the new rules. 00:04:37.290 --> 00:04:42.750 Yeah, that's maybe a little bit of a confusing example because Bitcoin did have a 00:04:42.750 --> 00:04:46.230 soft fork to bigger blocks a couple of years ago through SegWit. 00:04:46.470 --> 00:04:51.250 Well, that also points out that the idea that hard forks are bad and soft forks 00:04:51.250 --> 00:04:55.990 are good is not a great, like, it's not super accurate either because you can do 00:04:55.990 --> 00:04:59.170 all sorts of things with a soft fork that you think you can only do with a hard 00:04:59.170 --> 00:05:01.250 fork and vice versa. 00:05:01.550 --> 00:05:06.430 Right. But yeah, the point here is that the general sort of classic definition of 00:05:06.430 --> 00:05:11.790 a hard fork is it loosens or removes rules while a soft fork tightens or adds 00:05:11.790 --> 00:05:12.870 rules. Yeah. 00:05:13.030 --> 00:05:16.490 That's a very general definition. And the thing behind that is that because if 00:05:16.490 --> 00:05:20.430 you're running an old node, you're going to check the old rules basically. And if 00:05:20.430 --> 00:05:24.610 the new rules are more strict, then whatever the other nodes are doing, you'll 00:05:24.610 --> 00:05:27.770 still approve it because you still have a looser interpretation. 00:05:28.360 --> 00:05:33.340 Yeah, so especially if miners are enforcing the soft fork rules, then all the old 00:05:33.340 --> 00:05:38.200 nodes will still accept that chain as well. While with the hard fork, that's not 00:05:38.200 --> 00:05:42.940 necessarily the case. Now, what Jameson does in this blog post, 00:05:43.470 --> 00:05:48.990 in this lab post, is first of all, he 00:05:48.990 --> 00:05:54.330 proposes a stricter definition for hard fork. So he kind of 00:05:54.330 --> 00:06:00.200 adds... He adds two factors to what we 00:06:00.200 --> 00:06:05.340 should consider a hard fork or what he considers a hard fork. And then the second 00:06:05.340 --> 00:06:10.220 thing he does is he analyzes the history of Bitcoin to see if there have been any 00:06:10.220 --> 00:06:10.780 hard forks. 00:06:11.140 --> 00:06:11.280 Okay. 00:06:11.760 --> 00:06:17.620 Right. So what are, shall I just tell you what his new proposed definitions are? 00:06:18.040 --> 00:06:21.100 Yeah, that's probably a good idea because I didn't memorize them. 00:06:21.610 --> 00:06:27.210 Okay so he he [unclear] he... Classifications he proposes first of all, 00:06:27.210 --> 00:06:33.070 so a hard fork loosens the rules but what Jameson suggests is that 00:06:33.070 --> 00:06:39.050 it should really only be considered a hard fork if these looser rules 00:06:39.050 --> 00:06:40.750 are ever used. 00:06:42.360 --> 00:06:47.480 So you made the example of a block size limit increase. So I'll run with that 00:06:47.480 --> 00:06:51.880 example. And let's say 10 megabytes just to make it clear that we're talking 00:06:51.880 --> 00:06:57.680 about the hard fork here. So if a hard fork rule change is made that allows for 00:06:57.680 --> 00:07:03.450 10 megabytes blocks. But no 10 megabyte block is mined at all, all 00:07:03.450 --> 00:07:08.950 blocks are still one megabyte or two megabytes on their SegWit, then these looser 00:07:08.950 --> 00:07:14.150 rules are never actually used. So the older nodes, they wouldn't even notice that 00:07:14.150 --> 00:07:18.310 a hard fork happened at all. They would still just follow the chain. And 00:07:18.310 --> 00:07:22.890 therefore, under Lopp's definition, which I think is a reasonable definition, a 00:07:22.890 --> 00:07:24.570 hard fork never actually happened. 00:07:24.930 --> 00:07:27.870 Right, so you're risking a hard fork, but there's not an actual hard fork. 00:07:28.070 --> 00:07:32.050 Yeah, so it's only a hard fork if the rules are actually used. 00:07:32.550 --> 00:07:37.580 Yep. I can give an actual example of that, of something that happened fairly 00:07:37.580 --> 00:07:38.120 recently. 00:07:38.420 --> 00:07:41.200 Okay. Actually, we'll go over all of the examples later. 00:07:41.580 --> 00:07:42.060 Is that what we'll do? 00:07:42.320 --> 00:07:44.040 Let's first do the second rule. 00:07:44.180 --> 00:07:45.540 Okay. Or heuristic. 00:07:45.840 --> 00:07:51.440 Yeah, so the second classification is what I'm going with, or what Lopp is going 00:07:51.440 --> 00:07:56.380 with, actually, is implicit versus explicit. And that essentially means, 00:07:56.580 --> 00:08:02.230 was it intended to be a rule change? Or is it basically just a bug? 00:08:02.230 --> 00:08:07.190 Right but I would say a bug could still cause a hard fork but it's definitely a 00:08:07.190 --> 00:08:11.070 different kind of thing to deal with. Right if if the network because the one of 00:08:11.070 --> 00:08:13.650 the reasons you're worried about a hard fork is because it can split the network. 00:08:13.650 --> 00:08:19.030 And when that happens you want to know like okay is this split because we 00:08:19.030 --> 00:08:23.290 intended to change some of the rules or is this split some freak accident that we 00:08:23.290 --> 00:08:23.730 should fix? 00:08:24.260 --> 00:08:28.580 Yeah, well, I'm just explaining the classifications here. So right now, we've 00:08:28.580 --> 00:08:32.860 always been saying, you know, a hard fork, and we just gave the definition of 00:08:32.860 --> 00:08:38.320 that. And Lopp is suggesting we should make it more specific. What are we talking 00:08:38.320 --> 00:08:43.640 about exactly? Was it actually triggered or not? If not, it probably shouldn't 00:08:43.640 --> 00:08:47.060 even be considered a hard fork. And when I say triggered, I mean, were the new 00:08:47.060 --> 00:08:52.610 rules used? Was there a block mined that you know used the new rules? And then 00:08:52.610 --> 00:08:58.080 the second classification was it intentional or not? Okay then Lopp goes so 00:08:58.080 --> 00:09:03.170 that's the first half of the or that's sort of the new proposal for that's how we 00:09:03.170 --> 00:09:07.130 should think about hard forks more specifically. And then the second part of the 00:09:07.130 --> 00:09:12.970 blog post he goes over I think seven consensus changes in bitcoin's history that 00:09:12.970 --> 00:09:18.670 could be considered hard forks under any of these in any of these newer 00:09:18.670 --> 00:09:24.530 categories that I just gave, of which five are hard forks that were 00:09:24.530 --> 00:09:29.220 never triggered. In other words they were arguably not hard forks at all. And 00:09:29.220 --> 00:09:34.020 then there was one implicit hard fork. So a hard fork that was kind of just a bug 00:09:34.020 --> 00:09:40.040 and that wasn't intended to be there. And one explicit hard fork. So there's 00:09:40.040 --> 00:09:44.720 so one case where the rules were intentionally expanded and also somebody made 00:09:44.720 --> 00:09:46.260 use of those newly expanded rules. 00:09:46.260 --> 00:09:50.900 Exactly so in the sort of purest definition of a hard fork it only happened once. 00:09:50.900 --> 00:09:55.220 So it was like you said it was intended to happen and it actually happened that 00:09:55.220 --> 00:09:58.980 only happened once. Oh there's one other thing we should discuss which Lopp also 00:09:58.980 --> 00:10:03.140 mentioned and which I forgot so there's one other thing that people call hard 00:10:03.140 --> 00:10:09.110 forks I've never done that in my writing but that's fork coins so 00:10:09.110 --> 00:10:13.890 that's like Bitcoin cash or Bitcoin gold or whatever. We've had Bitcoin 00:10:13.890 --> 00:10:15.970 pizza Bitcoin pizza classic we've had 00:10:15.970 --> 00:10:21.410 dozens if not hundreds of these. So under some definitions of hard forks you 00:10:21.410 --> 00:10:26.110 could consider these hard forks. I've never done that I I think that if you 00:10:26.270 --> 00:10:30.630 intentionally create a new coin if it's obvious that that's what's going to 00:10:30.630 --> 00:10:34.730 happen if you're obviously going to split the blockchain and the and you're going 00:10:34.730 --> 00:10:39.300 to create a new token that will have a new ticker and that can be traded against 00:10:40.130 --> 00:10:44.450 the original, then I don't think that should even be thought of as hard fork even. 00:10:44.850 --> 00:10:48.490 I mean, it depends, I guess. It's in the eye of the beholder, right? I think with 00:10:48.490 --> 00:10:51.630 most of the forks of Bitcoin, it was pretty obvious that they were just forks. 00:10:51.930 --> 00:10:55.530 You could call them forks or airdrops or something like that. I go for 00:10:55.530 --> 00:10:56.390 fork coins, yeah. 00:10:56.610 --> 00:11:01.290 Yeah, but for example, in the case of Ethereum, it's a lot more ambiguous. If the 00:11:01.290 --> 00:11:05.230 entire community considers the current Ethereum to be Ethereum and the Ethereum 00:11:05.230 --> 00:11:06.750 Classic to be something else. 00:11:08.670 --> 00:11:12.450 But that's because I guess they also have a different philosophy around hard 00:11:12.450 --> 00:11:14.560 forks in general. They have a 00:11:14.560 --> 00:11:19.420 different philosophy. They actually have a literal registered trademark, you 00:11:19.420 --> 00:11:24.480 know, so the Ethereum Foundation can decide what must be called Ethereum. So 00:11:24.480 --> 00:11:29.260 that's one of the biggest differences between Bitcoin and Ethereum. It's 00:11:29.260 --> 00:11:33.180 centralized in that way. Yeah. Someone actually gets to make that decision. And 00:11:33.180 --> 00:11:36.970 in Bitcoin, we don't have that. So we need to sort of... Come to some kind of 00:11:36.970 --> 00:11:38.750 consensus on what language you use. 00:11:39.580 --> 00:11:44.760 Yeah, in any case, if the goal is to create two separate coins, then that's not 00:11:44.760 --> 00:11:46.160 the scenario that we're talking about here. 00:11:46.840 --> 00:11:50.460 Yeah, I would not consider that a hard fork, and neither does Jameson Lopp, at 00:11:50.460 --> 00:11:55.350 least in his blog post. Okay so now we've we that's out of the way, fork coins is 00:11:55.350 --> 00:11:59.050 not what we're talking about. And then we categorized different types of hard 00:11:59.050 --> 00:12:04.510 forks. And Lopp says there have been seven based on his research of which 00:12:04.510 --> 00:12:09.350 five were never triggered so they arguably weren't hard forks at all. One was 00:12:09.350 --> 00:12:12.750 implicit one was explicit. And now we're going to go over them is that right? 00:12:12.750 --> 00:12:13.290 Sounds good. 00:12:13.290 --> 00:12:18.630 Okay let's do it. So let's start with uh we're going to start with the five 00:12:19.460 --> 00:12:25.330 hard forks that were never triggered as does Lopp and I think this 00:12:25.620 --> 00:12:30.700 is where your expertise comes in Sjors, you're you're you can explain to our 00:12:30.700 --> 00:12:34.220 listeners what these five events were is that right? 00:12:34.220 --> 00:12:39.440 I will do my best I mostly studied the uh the final example where there was 00:12:40.070 --> 00:12:44.070 most arguably a hard fork. But we'll see if I remember the other five. 00:12:44.330 --> 00:12:49.570 Okay, so first, the first one was Satoshi changed best chain 00:12:49.570 --> 00:12:50.850 selection logic. 00:12:51.090 --> 00:12:51.770 Oh, yeah. 00:12:52.070 --> 00:12:54.810 That's Bitcoin 0.2. 00:12:55.580 --> 00:13:00.560 Yeah, that was a fun one, right? So from, I wasn't there and I haven't not 00:13:00.560 --> 00:13:03.520 actually looked at the change, but my understanding is that initially what 00:13:03.520 --> 00:13:07.760 Satoshi did was just saying, well, if there's more blocks, that must mean that 00:13:07.760 --> 00:13:11.680 that is the right chain to go to. Whereas now we would consider the most proof of 00:13:11.680 --> 00:13:16.260 work, the most cumulative proof of work to be the correct chain to go to. That's 00:13:16.260 --> 00:13:19.660 definitely a big change. And I think that was the intention too, you know, from 00:13:19.660 --> 00:13:23.610 the white paper. But it was implemented incorrectly in the beginning. 00:13:23.830 --> 00:13:25.570 Well, was that intention in the white paper? 00:13:25.650 --> 00:13:30.630 I don't think so. I think it was like one CPU, one vote. So if you extrapolate 00:13:30.630 --> 00:13:33.710 that, you would say that the more CPU power you have, the more votes you have. 00:13:34.050 --> 00:13:37.070 And the problem with the longest chain is that you can have a very high 00:13:37.070 --> 00:13:40.150 difficulty, but then the difficulty goes down because fewer people are mining. 00:13:41.620 --> 00:13:45.960 And you might end up with lots and lots of blocks at a very low difficulty and 00:13:45.960 --> 00:13:49.200 some obvious attacks because you can fake the timestamps and things like that. 00:13:49.460 --> 00:13:52.340 Yeah, that was definitely the philosophy in the white paper. But I think the way 00:13:52.340 --> 00:13:55.540 it was explained in the white paper, and it's been a while since I read it. I'm 00:13:55.540 --> 00:13:56.600 sure he would have used the word longest. 00:13:56.600 --> 00:14:00.660 And I think as a first approximation, that's fine. But if you really want to 00:14:00.660 --> 00:14:03.880 compare two chains, you don't just want to look at the number of blocks. You want 00:14:03.880 --> 00:14:05.620 to make sure that they actually have work. 00:14:06.690 --> 00:14:11.610 Exactly, yeah so before so apparently Bitcoin the very first version of Bitcoin 00:14:11.610 --> 00:14:14.770 they just looked at the longest chain that is essentially the highest block 00:14:14.770 --> 00:14:19.110 number is the chain that all nodes will converge on. And that was changed later 00:14:19.110 --> 00:14:19.870 to look at the 00:14:21.320 --> 00:14:27.080 most accumulated proof of work which is not technically a hard fork like it's not 00:14:27.080 --> 00:14:31.300 a loosening of the rules but it is a complete change of the rules. Yeah it's hard to 00:14:31.300 --> 00:14:34.420 see what would happen and I don't know if there's any documentation whether 00:14:34.420 --> 00:14:39.120 anything actually did happen whether he correctly anticipated this would become a 00:14:39.120 --> 00:14:42.820 problem or whether there were some really long chains with low proof of work out 00:14:42.820 --> 00:14:44.460 there that we just don't know about. 00:14:44.460 --> 00:14:50.370 Yeah well Jameson Lopp at least hasn't found any evidence that this was ever 00:14:50.370 --> 00:14:52.190 triggered. That's why it's in this category. 00:14:52.790 --> 00:14:53.930 Yeah, just keep in mind that the evidence... 00:14:53.930 --> 00:14:56.350 So according to him, there was never any change. 00:14:56.670 --> 00:15:00.210 Right, but keep in mind that such evidence would only exist on a forum or in some 00:15:00.210 --> 00:15:05.530 very, very old Bitcoiners node log file. Yeah, especially 00:15:05.530 --> 00:15:11.450 because... Bitcoin version 2 was probably released 2009 still? Or 00:15:11.450 --> 00:15:12.370 what do you think? 00:15:12.970 --> 00:15:15.190 Yeah, I'd say 2009 to 2010. Yeah, 00:15:15.370 --> 00:15:20.360 so that were basically probably 10 people paying attention. Something like that. 00:15:20.940 --> 00:15:21.780 If that. 00:15:22.020 --> 00:15:22.720 That and the NSA. 00:15:23.380 --> 00:15:24.240 Right, of course. 00:15:27.670 --> 00:15:29.850 Okay, the next one is... 00:15:31.470 --> 00:15:33.570 OP_VER. Do you know what OP_VER is? 00:15:33.770 --> 00:15:37.690 Yeah, OP_VER is a fun one. It's not named after Roger Ver. It was actually before 00:15:37.690 --> 00:15:38.390 he was involved. 00:15:40.070 --> 00:15:43.240 No, I don't. Was it? 3.6. 00:15:43.460 --> 00:15:47.300 I mean, it was in there from the beginning, right? That's probably before Roger 00:15:47.300 --> 00:15:48.420 Ver was involved. 00:15:48.620 --> 00:15:49.100 Yeah, you're right. 00:15:49.620 --> 00:15:55.500 So basically what OP_VER did was it would use the version of the protocol or the 00:15:55.500 --> 00:16:00.560 version, kind of like the version of the software as a part of the script. So you 00:16:00.560 --> 00:16:04.420 could send somebody money and saying, okay, you can redeem this if the software 00:16:04.420 --> 00:16:08.350 version is two. And so you would be running software version two, and you would 00:16:08.350 --> 00:16:12.270 just take these coins and say, okay, I'm happy. My software version is two. And 00:16:12.270 --> 00:16:13.050 then I would wait a while. 00:16:14.450 --> 00:16:18.810 And then software version would maybe be three, or the miner might be running 00:16:18.810 --> 00:16:21.910 version three, and I would send the same transaction to that miner, and they 00:16:21.910 --> 00:16:25.690 would be like, no, this transaction is not actually valid. So you create a fork, 00:16:25.890 --> 00:16:28.910 because whether a transaction is valid depends on which version of the software 00:16:28.910 --> 00:16:33.070 you're running. So that was obviously not a very good security thing. 00:16:33.390 --> 00:16:37.530 Right, so OP_VER, that opcode was just removed entirely from the protocol. 00:16:37.950 --> 00:16:40.530 Yeah, though that sounds like a soft fork to me, so I'm not sure why. 00:16:40.810 --> 00:16:42.710 No, removing it would be a hard fork, right? 00:16:42.940 --> 00:16:46.080 No, you're limiting the rules. You're saying you cannot use this rule anymore. 00:16:49.400 --> 00:16:52.860 So maybe there was something more subtle going on, but just generally when you 00:16:52.860 --> 00:16:57.330 disable an opcode, which has been done countless times, you're basically saying 00:16:57.330 --> 00:17:00.510 this opcode can no longer be used, so you're limiting the number of transactions 00:17:00.510 --> 00:17:05.860 that are valid, which is a soft fork. But maybe there was something more subtle. Wait, 00:17:05.920 --> 00:17:08.820 so why do you think Lopp lists as a hard fork? 00:17:10.040 --> 00:17:15.070 Well, there's two possibilities, actually. One is that... Maybe the change was 00:17:15.070 --> 00:17:20.630 not to make it illegal to use OP_EVAL, but maybe it would have... Sorry, OP_VER, 00:17:21.090 --> 00:17:25.510 but maybe it would have been interpreted as meaning it's always valid, in which 00:17:25.510 --> 00:17:29.170 case you are increasing the number of valid scripts. But the other option is that 00:17:29.170 --> 00:17:34.190 what he was trying to say is the use of OP_VER could have caused many hard forks 00:17:34.190 --> 00:17:39.050 at many times. Because as soon as somebody sends it, like you have two miners in 00:17:39.050 --> 00:17:42.390 the system, you have one miner running version two and the other mining running 00:17:42.390 --> 00:17:45.850 version three, then one of the miners would consider it chain valid, the other 00:17:45.850 --> 00:17:49.880 would consider it invalid. That would definitely be a chain split. Right. But I 00:17:49.880 --> 00:17:52.140 don't know if you'd classify it as a hard fork. Definitely bad. 00:17:52.340 --> 00:17:57.180 Well, that makes sense what you just said. Yeah. Anyways, the bottom line is 00:17:57.180 --> 00:18:02.620 OP_VER was never used at all. So that's why it wasn't actually a hard fork. 00:18:02.740 --> 00:18:05.200 Well, it was never used in the history of the blockchain that we're currently 00:18:05.200 --> 00:18:05.780 aware of. 00:18:06.420 --> 00:18:12.160 Fair point. Next one is the separation of the evaluation of the 00:18:12.160 --> 00:18:14.620 scriptSig and scriptPubKey. 00:18:14.930 --> 00:18:18.510 Yeah, that was funny. It used to be that you could just take anybody's Bitcoin 00:18:18.510 --> 00:18:24.460 and now you can't take anybody's Bitcoin. Though I would say that's a soft fork. 00:18:24.940 --> 00:18:27.100 Yeah, that also sounds like a soft fork, doesn't it? 00:18:27.260 --> 00:18:31.300 Yeah, but there may be a subtlety similar to what we just talked about. 00:18:31.580 --> 00:18:31.720 Right. 00:18:32.100 --> 00:18:36.300 But yeah, it used to be that I think if your script, anywhere in your script had 00:18:36.300 --> 00:18:40.920 op return into it, it would just say, okay, I guess the script is valid. And then 00:18:40.920 --> 00:18:46.060 the person spending your coins could say, okay, I'm just going to start my script 00:18:46.060 --> 00:18:48.760 with op return and I'm going to take your coins now. 00:18:49.850 --> 00:18:54.430 Anyways this was clearly a bug and it was also never used. So therefore it's in 00:18:54.430 --> 00:18:58.650 this category of you know hypothetical hard forks that never happened and 00:18:58.650 --> 00:19:02.610 therefore arguably weren't a hard fork at all. Then we have the critical 00:19:02.610 --> 00:19:08.190 inflation bug of Bitcoin core 15 so this was relative recently 00:19:08.190 --> 00:19:10.890 yeah that was funny you remember that one I think 00:19:11.280 --> 00:19:17.260 Yep. So basically there was a bug introduced in 0.15 that would 00:19:17.260 --> 00:19:22.880 have allowed inflation, but only if your node was still running. So if a miner 00:19:22.880 --> 00:19:28.800 produced a block with inflation, your node would accept it. But I think if 00:19:28.800 --> 00:19:33.480 you shut down the node and have it sync again, it would not. So it would 00:19:33.480 --> 00:19:34.520 definitely create confusion. 00:19:35.800 --> 00:19:40.600 And that rule was later removed. So you could say to allow inflation is... It's 00:19:40.600 --> 00:19:44.500 creating the risk of a hard fork. But since nobody actually produced inflation 00:19:44.500 --> 00:19:47.740 and the rule is then removed, nothing happened. 00:19:48.060 --> 00:19:52.700 Yeah, it was fixed in September 2018. So for three years, people could have 00:19:52.700 --> 00:19:54.460 created inflation on Bitcoin. 00:19:54.960 --> 00:19:58.840 Yeah, my guess is they would have created chaos on Bitcoin. But I don't think 00:19:58.840 --> 00:20:04.320 that those newly created coins would have ever been stored in any of the longest chains. 00:20:05.270 --> 00:20:10.140 Yeah. Fair enough. Anyways, the bug was never abused, 00:20:10.160 --> 00:20:15.340 and it was fixed, and therefore it's also one of these hypothetical hard forks 00:20:15.340 --> 00:20:18.500 that never actually happened, and therefore arguably weren't a hard fork at all. 00:20:18.940 --> 00:20:24.910 Then the last one, we actually made an episode about this one. This is burying 00:20:24.910 --> 00:20:29.480 soft forks, BIP-90. That was episode 54. 00:20:29.820 --> 00:20:34.100 Yeah, so I think what burying soft forks does is it basically says that the 00:20:34.100 --> 00:20:39.240 rules, say with SegWit, for example, which has been buried, at least in Bitcoin 00:20:39.240 --> 00:20:44.280 Core software, I think in others too, if there ever was an alien race creating a 00:20:44.280 --> 00:20:48.140 reorg back to the Genesis block, those new blocks would have to follow SegWit. 00:20:48.700 --> 00:20:54.320 And so... If you have an old node that didn't care about SegWit, it might 00:20:54.320 --> 00:20:59.290 actually accept the different chain as valid as the new nodes. Again, isn't that 00:20:59.290 --> 00:20:59.750 a soft fork? 00:21:00.290 --> 00:21:05.130 Yeah, but it would create a hard fork, I guess, from the old nodes. I guess I 00:21:05.130 --> 00:21:09.030 would tend to agree with you again. That does sound more like a soft fork. Well, it's 00:21:09.030 --> 00:21:13.370 possible that the aliens create two chains, right? So they create one very long 00:21:13.370 --> 00:21:19.180 chain that does not obey SegWit. And the old nodes would think 00:21:19.180 --> 00:21:23.700 that's fine, and then it would create a shorter chain that does obey Segwit, and 00:21:23.700 --> 00:21:28.720 the new nodes would go for that one. So then the old nodes would be following a 00:21:28.720 --> 00:21:32.460 different chain. So I guess you would say that's a hard fork, or at least it's a chain split. 00:21:32.840 --> 00:21:37.920 Yeah, well, we discussed this in full in episode 54, as I mentioned, and why it's 00:21:37.920 --> 00:21:40.760 debatable whether this is a risk that should be taken. 00:21:41.600 --> 00:21:45.300 And whether the effect of the alien invasion is perhaps a higher priority. 00:21:47.090 --> 00:21:48.650 Higher priority than Bitcoin. 00:21:49.030 --> 00:21:52.010 Than trying to fix that particular issue with SegWit rules. 00:21:52.230 --> 00:21:55.810 In case it wasn't clear this also never happened, and it's not plausible to ever 00:21:55.810 --> 00:21:59.930 become a real problem because like you said we would need a very long reorg etc 00:21:59.930 --> 00:22:04.150 etc. So these were the hypothetical hardforks that were never actually triggered 00:22:04.150 --> 00:22:07.310 and therefore arguably shouldn't be considered hardfork at all. 00:22:08.560 --> 00:22:14.350 Then we get to the implicit consensus change implicit hard fork so 00:22:14.350 --> 00:22:19.670 which was essentially a bug but which did trigger a hard fork that's 00:22:19.670 --> 00:22:22.860 the Have we discussed this on our episode? 00:22:23.060 --> 00:22:25.820 Yeah, we brought it up a few times. So basically it differs in database 00:22:25.820 --> 00:22:26.400 configuration. 00:22:26.400 --> 00:22:30.240 We discussed this on the previous episode where we discussed one of Jameson 00:22:30.380 --> 00:22:34.900 Lopp's blog posts running, syncing old Bitcoin nodes, I think. So that was 00:22:34.900 --> 00:22:35.640 episode 55. 00:22:35.900 --> 00:22:37.500 Yeah, and I think we've covered it earlier too. 00:22:37.680 --> 00:22:42.500 Of dependencies and yeah. So yeah, this was BIP50 where, 00:22:43.080 --> 00:22:48.990 let's see, Bitcoin Core... 8? Yeah. 8.0. 0.8. 00:22:49.130 --> 00:22:54.390 It became incompatible with previous versions due to a dependency on the Berkeley 00:22:54.390 --> 00:22:55.790 DB database. Is that right? 00:22:56.210 --> 00:23:01.550 Yeah. So I think what happened is the original version of 0.7, et cetera, 00:23:01.770 --> 00:23:07.590 used Berkeley database and... And it 00:23:07.590 --> 00:23:11.470 configured the Berkeley database with some limitations. And I think one of the 00:23:11.470 --> 00:23:16.370 limitations was basically boiled down to a maximum number of transactions that 00:23:16.370 --> 00:23:20.550 could fit in a block, like 10,000. And then it was Bitcoin Core was upgraded to a 00:23:20.550 --> 00:23:24.780 new database format that did not come with any of those limitations. So 00:23:24.780 --> 00:23:29.040 basically, as soon as you produced a block with more than, I think, 10,000 00:23:29.040 --> 00:23:32.740 transactions, the old nodes would say, hey, this is not a valid block. 00:23:35.280 --> 00:23:39.460 And then the new nodes would say, no, it's perfectly fine. And there was never 00:23:39.460 --> 00:23:42.540 intended to be that type of limit on the number of transactions. It was just a 00:23:42.540 --> 00:23:47.020 configuration of the database that wasn't thought through well enough that it 00:23:47.020 --> 00:23:50.400 would have that implication. Or at least as far as we know, because I don't think 00:23:50.400 --> 00:23:54.600 Satoshi ever documented saying, hey, by the way, this little limit in the 00:23:54.600 --> 00:23:55.640 database is important. 00:23:55.960 --> 00:24:01.760 Yeah, so this was a bug based on a dependency, essentially. And this one 00:24:01.760 --> 00:24:07.710 did actually trigger... A hard fork and also an actual chain split. So for a 00:24:07.710 --> 00:24:12.530 couple of hours, for about five hours, there were two incompatible Bitcoin 00:24:12.530 --> 00:24:13.270 blockchains. 00:24:13.570 --> 00:24:18.370 Yeah, exactly. And people actually had to come to consensus very quickly to 00:24:18.370 --> 00:24:20.230 decide which side to go for. 00:24:20.450 --> 00:24:24.850 Yeah, and the side they went for was the previous blockchain, the non-hard fork 00:24:24.850 --> 00:24:28.990 blockchain, essentially. So now if you look at the Bitcoin blockchain, there's no 00:24:28.990 --> 00:24:34.540 trace of a hard fork happening, right? But there was... For a short time, for 00:24:34.540 --> 00:24:35.140 five hours. 00:24:35.400 --> 00:24:39.420 So I think the decision was to use the old rules, to keep using the old rules, 00:24:39.500 --> 00:24:42.880 even though these old rules were accidental, to keep using those accidental rules 00:24:42.880 --> 00:24:47.980 for a while, but then later on to relax them. And then it turns into one of those 00:24:47.980 --> 00:24:52.200 potential hard forks where it could have happened, but nobody actually triggered 00:24:52.200 --> 00:24:52.680 the condition. 00:24:53.440 --> 00:24:57.820 No, they were triggered later. That's what Lopp explains in the blog post. 00:25:01.260 --> 00:25:04.280 Oh, right. Even pause om dat goed op te zoeken. 00:25:04.480 --> 00:25:05.280 No, I think you're right. 00:25:05.500 --> 00:25:07.420 It was triggered later, I think. 00:25:07.620 --> 00:25:11.320 That's right. So, well, it was triggered immediately, but that part of history 00:25:11.320 --> 00:25:15.960 has been removed. And then, because it was unexpected and people wanted to have 00:25:15.960 --> 00:25:19.840 some time to regroup and think about what to do about it. But then later on, the 00:25:19.840 --> 00:25:25.720 rules were relaxed to actually allow basically whatever size, whatever 00:25:25.720 --> 00:25:30.330 number of transactions would actually fit into the limit of the block. And that 00:25:30.330 --> 00:25:34.530 eventually ended up happening. So there was a time when if you were still running 00:25:34.530 --> 00:25:38.450 that old version of the node, you would not have accepted the new blocks. And 00:25:38.450 --> 00:25:41.970 then you had the choice between either upgrading to the new node version or 00:25:41.970 --> 00:25:43.750 changing one configuration. 00:25:44.830 --> 00:25:49.210 So why was that never a problem? Was it never a problem because everyone upgraded 00:25:49.210 --> 00:25:49.750 by the node? 00:25:49.950 --> 00:25:53.150 No, it was a problem. If you didn't change that configuration, your node would be 00:25:53.150 --> 00:25:56.300 in trouble. So that's why you had... Some amount of time to do that. 00:25:56.300 --> 00:25:58.400 That was new to me actually I didn't know that. 00:25:58.400 --> 00:26:00.900 And I don't think it was very long either it's probably a month. 00:26:00.900 --> 00:26:05.500 Yeah it seems like a bit more than a month but um so 00:26:05.500 --> 00:26:10.580 you you had a month to do the upgrade. That was when the safety net went away. 00:26:10.780 --> 00:26:14.180 But before somebody actually produced a block that big, it might have been 00:26:14.180 --> 00:26:15.180 longer. Okay, 00:26:15.300 --> 00:26:21.240 Sjors, the thing is 0.8.0 was released in March. That's when 00:26:21.240 --> 00:26:27.180 the accidental split happened. And then shortly thereafter, Bitcoin 0.8 00:26:27.180 --> 00:26:33.180 .1 was released, which had some virtual limits to prevent 00:26:33.180 --> 00:26:38.930 the blockchain from splitting. This expired in May. But then the first time it 00:26:38.930 --> 00:26:44.670 was triggered was in September 2013. But then it 00:26:44.670 --> 00:26:49.930 only sort of triggered it compared to Bitcoin Core 0.5 nodes 00:26:49.930 --> 00:26:55.530 and earlier. And then a couple of years later in 2015. 00:26:56.340 --> 00:27:00.920 It was triggered again, and this time it affected Bitcoin Core 6 and 7 nodes. 00:27:01.120 --> 00:27:05.260