Episode 59: Has Bitcoin Ever Hard Forked?

Aaron van Wirdum Live from Utrecht, this is Bitcoin. Explained. Hey Sjors.

Sjors Provoost What's up?

Aaron van Wirdum How's life in the McDrive?

Sjors Provoost Excellent. Well, it's the McWalk now, I guess, because, you know.

Aaron van Wirdum You don't even have a car anymore.

Sjors Provoost No, you work there, right?

Aaron van Wirdum We both work there now.

Sjors Provoost Oh, you mean life from the McDrive.

Aaron van Wirdum Yeah, no, it's great. I actually used to work at McDonald's in my teenage years.

Sjors Provoost Okay.

Aaron van Wirdum It was kind of fun.

Sjors Provoost I was more into newspaper delivery and that sort of stuff.

Aaron van Wirdum Oh, yeah, sure. So I got a question.

Sjors Provoost Great. Tell me.

Aaron van Wirdum From one of our listeners. From Vinay Shetty. It's a question from a while ago, actually, but we're finally going to address it. Before we get into the actual episode. By the way, the actual episode is about James Lopp's hard fork research. So our listeners also know this now. But we're first going to address a quick question from one of our listeners, which is, Sjors, are you ready?

Sjors Provoost I'm ready.

Aaron van Wirdum So the tweet is curious on how the DNS seeders work when the node is set up as an onion node. I set up a prune node and all I had was dot onion outgoing connections. Am I querying the DNS seeders for that information? Or do I get that information from the hard-coded file? Sjors?

Sjors Provoost Well, assuming this tweet was not written three years ago.

Aaron van Wirdum It was written like two months ago.

Sjors Provoost Okay. Because with Tor v2, it was a little bit different. But we had an episode where we explained the difference between Tor v2 and Tor v3. But with Tor v3, it's very safe to say that you did not get that from the DNS seeds. So what happens is when your node starts up... It will query the DNS seeds to see if there's other nodes out there. But if you configured your node to only connect to Tor nodes, then it won't find anything because the DNS seeds are not actually telling you where the Tor nodes are. It only knows where the IPv4 nodes are and where the IPv6 nodes are. So that means if you didn't run your node before, like ever, without Tor, then the only way you would have found those onion addresses that you connected to now is because you found one that was hard-coded in the source code. So basically, if the DNS seeds don't give you anything useful... Which would be the case, right? If you're asking them for Tor addresses, but you're only getting IPv4 and IPv6 addresses, then your node is going to fall back to some hard-coded Tor addresses that are in the source code. And if any of those still exist, it will connect to them, and then it will get a bunch of other Tor services from that first connection, and then you'll connect to those.

Aaron van Wirdum Okay. Vinay, I hope that helps. Sjors, let's get into the main topic of this episode. All right. Oh, and if any other listeners, you know, if you have questions or if you have an idea for a topic we can discuss for an entire episode, feel free to let us know on Twitter. I'm at Aaron Van W. And Sjors is at provoost.

Sjors Provoost That's right. And if you want the answer a bit quicker than three weeks, you should probably also ask Bitcoin Stack Exchange.

Aaron van Wirdum All right, Sjors, on to the main topic. All right. So Jameson Lopp wrote another excellent blog post. We've discussed one of his blog posts before. I think that was Syncing Old Nodes, episode 55. Cool. I'm pretty sure it was 55. I'm actually almost entirely sure it was 55. And this time he published a blog post called Has Bitcoin Ever Hard Forked? So it discusses whether Bitcoin has ever hard forked, obviously. Okay. First of all, I'll just ask you right now, what is a hard fork?

Sjors Provoost Well, as Lopp actually points out in the blog post, it's a bit of an ambiguous term, but generally what we mean is it's a loosening of the rules. I mean, it's only a fork if something actually happens. Or at least that's what we could debate about. But generally, the difference between a hard fork and a soft fork is to say, in a hard fork, you're loosening the rules. So, for example, you might be allowing 2 megabyte blocks instead of 1 megabyte blocks. And a soft fork would be tightening the rules. So you might say, we're only going to allow smaller blocks. And this matters in terms of whether or not you need to upgrade very quickly to be able to follow the new rules.

Aaron van Wirdum Yeah, that's maybe a little bit of a confusing example because Bitcoin did have a soft fork to bigger blocks a couple of years ago through SegWit.

Sjors Provoost Well, that also points out that the idea that hard forks are bad and soft forks are good is not a great, like, it's not super accurate either because you can do all sorts of things with a soft fork that you think you can only do with a hard fork and vice versa.

Aaron van Wirdum Right. But yeah, the point here is that the general sort of classic definition of a hard fork is it loosens or removes rules while a soft fork tightens or adds rules. Yeah.

Sjors Provoost That's a very general definition. And the thing behind that is that because if you're running an old node, you're going to check the old rules basically. And if the new rules are more strict, then whatever the other nodes are doing, you'll still approve it because you still have a looser interpretation.

Aaron van Wirdum Yeah, so especially if miners are enforcing the soft fork rules, then all the old nodes will still accept that chain as well. While with the hard fork, that's not necessarily the case. Now, what Jameson does in this blog post, in this lab post, is first of all, he proposes a stricter definition for hard fork. So he kind of adds... He adds two factors to what we should consider a hard fork or what he considers a hard fork. And then the second thing he does is he analyzes the history of Bitcoin to see if there have been any hard forks.

Sjors Provoost Okay.

Aaron van Wirdum Right. So what are, shall I just tell you what his new proposed definitions are?

Sjors Provoost Yeah, that's probably a good idea because I didn't memorize them.

Aaron van Wirdum Okay so he he [unclear] he... Classifications he proposes first of all, so a hard fork loosens the rules but what Jameson suggests is that it should really only be considered a hard fork if these looser rules are ever used. So you made the example of a block size limit increase. So I'll run with that example. And let's say 10 megabytes just to make it clear that we're talking about the hard fork here. So if a hard fork rule change is made that allows for 10 megabytes blocks. But no 10 megabyte block is mined at all, all blocks are still one megabyte or two megabytes on their SegWit, then these looser rules are never actually used. So the older nodes, they wouldn't even notice that a hard fork happened at all. They would still just follow the chain. And therefore, under Lopp's definition, which I think is a reasonable definition, a hard fork never actually happened.

Sjors Provoost Right, so you're risking a hard fork, but there's not an actual hard fork.

Aaron van Wirdum Yeah, so it's only a hard fork if the rules are actually used.

Sjors Provoost Yep. I can give an actual example of that, of something that happened fairly recently.

Aaron van Wirdum Okay. Actually, we'll go over all of the examples later.

Sjors Provoost Is that what we'll do?

Aaron van Wirdum Let's first do the second rule.

Sjors Provoost Okay. Or heuristic.

Aaron van Wirdum Yeah, so the second classification is what I'm going with, or what Lopp is going with, actually, is implicit versus explicit. And that essentially means, was it intended to be a rule change? Or is it basically just a bug?

Sjors Provoost Right but I would say a bug could still cause a hard fork but it's definitely a different kind of thing to deal with. Right if if the network because the one of the reasons you're worried about a hard fork is because it can split the network. And when that happens you want to know like okay is this split because we intended to change some of the rules or is this split some freak accident that we should fix?

Aaron van Wirdum Yeah, well, I'm just explaining the classifications here. So right now, we've always been saying, you know, a hard fork, and we just gave the definition of that. And Lopp is suggesting we should make it more specific. What are we talking about exactly? Was it actually triggered or not? If not, it probably shouldn't even be considered a hard fork. And when I say triggered, I mean, were the new rules used? Was there a block mined that you know used the new rules? And then the second classification was it intentional or not? Okay then Lopp goes so that's the first half of the or that's sort of the new proposal for that's how we should think about hard forks more specifically. And then the second part of the blog post he goes over I think seven consensus changes in bitcoin's history that could be considered hard forks under any of these in any of these newer categories that I just gave, of which five are hard forks that were never triggered. In other words they were arguably not hard forks at all. And then there was one implicit hard fork. So a hard fork that was kind of just a bug and that wasn't intended to be there. And one explicit hard fork. So there's

Sjors Provoost so one case where the rules were intentionally expanded and also somebody made use of those newly expanded rules.

Aaron van Wirdum Exactly so in the sort of purest definition of a hard fork it only happened once. So it was like you said it was intended to happen and it actually happened that only happened once. Oh there's one other thing we should discuss which Lopp also mentioned and which I forgot so there's one other thing that people call hard forks I've never done that in my writing but that's fork coins so that's like Bitcoin cash or Bitcoin gold or whatever. We've had Bitcoin

Sjors Provoost pizza Bitcoin pizza classic we've had

Aaron van Wirdum dozens if not hundreds of these. So under some definitions of hard forks you could consider these hard forks. I've never done that I I think that if you intentionally create a new coin if it's obvious that that's what's going to happen if you're obviously going to split the blockchain and the and you're going to create a new token that will have a new ticker and that can be traded against the original, then I don't think that should even be thought of as hard fork even.

Sjors Provoost I mean, it depends, I guess. It's in the eye of the beholder, right? I think with most of the forks of Bitcoin, it was pretty obvious that they were just forks. You could call them forks or airdrops or something like that. I go for

Aaron van Wirdum fork coins, yeah.

Sjors Provoost Yeah, but for example, in the case of Ethereum, it's a lot more ambiguous. If the entire community considers the current Ethereum to be Ethereum and the Ethereum Classic to be something else. But that's because I guess they also have a different philosophy around hard forks in general. They have a

Aaron van Wirdum different philosophy. They actually have a literal registered trademark, you know, so the Ethereum Foundation can decide what must be called Ethereum. So that's one of the biggest differences between Bitcoin and Ethereum. It's centralized in that way. Yeah. Someone actually gets to make that decision. And in Bitcoin, we don't have that. So we need to sort of... Come to some kind of consensus on what language you use.

Sjors Provoost Yeah, in any case, if the goal is to create two separate coins, then that's not the scenario that we're talking about here.

Aaron van Wirdum Yeah, I would not consider that a hard fork, and neither does Jameson Lopp, at least in his blog post. Okay so now we've we that's out of the way, fork coins is not what we're talking about. And then we categorized different types of hard forks. And Lopp says there have been seven based on his research of which five were never triggered so they arguably weren't hard forks at all. One was implicit one was explicit. And now we're going to go over them is that right?

Sjors Provoost Sounds good.

Aaron van Wirdum Okay let's do it. So let's start with uh we're going to start with the five hard forks that were never triggered as does Lopp and I think this is where your expertise comes in Sjors, you're you're you can explain to our listeners what these five events were is that right?

Sjors Provoost I will do my best I mostly studied the uh the final example where there was most arguably a hard fork. But we'll see if I remember the other five.

Aaron van Wirdum Okay, so first, the first one was Satoshi changed best chain selection logic.

Sjors Provoost Oh, yeah.

Aaron van Wirdum That's Bitcoin 0.2.

Sjors Provoost Yeah, that was a fun one, right? So from, I wasn't there and I haven't not actually looked at the change, but my understanding is that initially what Satoshi did was just saying, well, if there's more blocks, that must mean that that is the right chain to go to. Whereas now we would consider the most proof of work, the most cumulative proof of work to be the correct chain to go to. That's definitely a big change. And I think that was the intention too, you know, from the white paper. But it was implemented incorrectly in the beginning.

Aaron van Wirdum Well, was that intention in the white paper?

Sjors Provoost I don't think so. I think it was like one CPU, one vote. So if you extrapolate that, you would say that the more CPU power you have, the more votes you have. And the problem with the longest chain is that you can have a very high difficulty, but then the difficulty goes down because fewer people are mining. And you might end up with lots and lots of blocks at a very low difficulty and some obvious attacks because you can fake the timestamps and things like that.

Aaron van Wirdum Yeah, that was definitely the philosophy in the white paper. But I think the way it was explained in the white paper, and it's been a while since I read it. I'm sure he would have used the word longest.

Sjors Provoost And I think as a first approximation, that's fine. But if you really want to compare two chains, you don't just want to look at the number of blocks. You want to make sure that they actually have work.

Aaron van Wirdum Exactly, yeah so before so apparently Bitcoin the very first version of Bitcoin they just looked at the longest chain that is essentially the highest block number is the chain that all nodes will converge on. And that was changed later to look at the most accumulated proof of work which is not technically a hard fork like it's not a loosening of the rules but it is a complete change of the rules. Yeah it's hard to

Sjors Provoost see what would happen and I don't know if there's any documentation whether anything actually did happen whether he correctly anticipated this would become a problem or whether there were some really long chains with low proof of work out there that we just don't know about.

Aaron van Wirdum Yeah well Jameson Lopp at least hasn't found any evidence that this was ever triggered. That's why it's in this category.

Sjors Provoost Yeah, just keep in mind that the evidence...

Aaron van Wirdum So according to him, there was never any change.

Sjors Provoost Right, but keep in mind that such evidence would only exist on a forum or in some very, very old Bitcoiners node log file. Yeah, especially

Aaron van Wirdum because... Bitcoin version 2 was probably released 2009 still? Or what do you think?

Sjors Provoost Yeah, I'd say 2009 to 2010. Yeah,

Aaron van Wirdum so that were basically probably 10 people paying attention. Something like that. If that.

Sjors Provoost That and the NSA.

Aaron van Wirdum Right, of course. Okay, the next one is... OP_VER. Do you know what OP_VER is?

Sjors Provoost Yeah, OP_VER is a fun one. It's not named after Roger Ver. It was actually before he was involved.

Aaron van Wirdum No, I don't. Was it? 3.6.

Sjors Provoost I mean, it was in there from the beginning, right? That's probably before Roger Ver was involved.

Aaron van Wirdum Yeah, you're right.

Sjors Provoost So basically what OP_VER did was it would use the version of the protocol or the version, kind of like the version of the software as a part of the script. So you could send somebody money and saying, okay, you can redeem this if the software version is two. And so you would be running software version two, and you would just take these coins and say, okay, I'm happy. My software version is two. And then I would wait a while. And then software version would maybe be three, or the miner might be running version three, and I would send the same transaction to that miner, and they would be like, no, this transaction is not actually valid. So you create a fork, because whether a transaction is valid depends on which version of the software you're running. So that was obviously not a very good security thing.

Aaron van Wirdum Right, so OP_VER, that opcode was just removed entirely from the protocol.

Sjors Provoost Yeah, though that sounds like a soft fork to me, so I'm not sure why.

Aaron van Wirdum No, removing it would be a hard fork, right?

Sjors Provoost No, you're limiting the rules. You're saying you cannot use this rule anymore. So maybe there was something more subtle going on, but just generally when you disable an opcode, which has been done countless times, you're basically saying this opcode can no longer be used, so you're limiting the number of transactions that are valid, which is a soft fork. But maybe there was something more subtle. Wait,

Aaron van Wirdum so why do you think Lopp lists as a hard fork?

Sjors Provoost Well, there's two possibilities, actually. One is that... Maybe the change was not to make it illegal to use OP_EVAL, but maybe it would have... Sorry, OP_VER, but maybe it would have been interpreted as meaning it's always valid, in which case you are increasing the number of valid scripts. But the other option is that what he was trying to say is the use of OP_VER could have caused many hard forks at many times. Because as soon as somebody sends it, like you have two miners in the system, you have one miner running version two and the other mining running version three, then one of the miners would consider it chain valid, the other would consider it invalid. That would definitely be a chain split. Right. But I don't know if you'd classify it as a hard fork. Definitely bad.

Aaron van Wirdum Well, that makes sense what you just said. Yeah. Anyways, the bottom line is OP_VER was never used at all. So that's why it wasn't actually a hard fork.

Sjors Provoost Well, it was never used in the history of the blockchain that we're currently aware of.

Aaron van Wirdum Fair point. Next one is the separation of the evaluation of the scriptSig and scriptPubKey.

Sjors Provoost Yeah, that was funny. It used to be that you could just take anybody's Bitcoin and now you can't take anybody's Bitcoin. Though I would say that's a soft fork.

Aaron van Wirdum Yeah, that also sounds like a soft fork, doesn't it?

Sjors Provoost Yeah, but there may be a subtlety similar to what we just talked about.

Aaron van Wirdum Right.

Sjors Provoost But yeah, it used to be that I think if your script, anywhere in your script had op return into it, it would just say, okay, I guess the script is valid. And then the person spending your coins could say, okay, I'm just going to start my script with op return and I'm going to take your coins now.

Aaron van Wirdum Anyways this was clearly a bug and it was also never used. So therefore it's in this category of you know hypothetical hard forks that never happened and therefore arguably weren't a hard fork at all. Then we have the critical inflation bug of Bitcoin core 15 so this was relative recently yeah that was funny you remember that one I think

Sjors Provoost Yep. So basically there was a bug introduced in 0.15 that would have allowed inflation, but only if your node was still running. So if a miner produced a block with inflation, your node would accept it. But I think if you shut down the node and have it sync again, it would not. So it would definitely create confusion. And that rule was later removed. So you could say to allow inflation is... It's creating the risk of a hard fork. But since nobody actually produced inflation and the rule is then removed, nothing happened.

Aaron van Wirdum Yeah, it was fixed in September 2018. So for three years, people could have created inflation on Bitcoin.

Sjors Provoost Yeah, my guess is they would have created chaos on Bitcoin. But I don't think that those newly created coins would have ever been stored in any of the longest chains.

Aaron van Wirdum Yeah. Fair enough. Anyways, the bug was never abused, and it was fixed, and therefore it's also one of these hypothetical hard forks that never actually happened, and therefore arguably weren't a hard fork at all. Then the last one, we actually made an episode about this one. This is burying soft forks, BIP-90. That was episode 54.

Sjors Provoost Yeah, so I think what burying soft forks does is it basically says that the rules, say with SegWit, for example, which has been buried, at least in Bitcoin Core software, I think in others too, if there ever was an alien race creating a reorg back to the Genesis block, those new blocks would have to follow SegWit. And so... If you have an old node that didn't care about SegWit, it might actually accept the different chain as valid as the new nodes. Again, isn't that a soft fork?

Aaron van Wirdum Yeah, but it would create a hard fork, I guess, from the old nodes. I guess I would tend to agree with you again. That does sound more like a soft fork. Well, it's

Sjors Provoost possible that the aliens create two chains, right? So they create one very long chain that does not obey SegWit. And the old nodes would think that's fine, and then it would create a shorter chain that does obey Segwit, and the new nodes would go for that one. So then the old nodes would be following a different chain. So I guess you would say that's a hard fork, or at least it's a chain split.

Aaron van Wirdum Yeah, well, we discussed this in full in episode 54, as I mentioned, and why it's debatable whether this is a risk that should be taken.

Sjors Provoost And whether the effect of the alien invasion is perhaps a higher priority.

Aaron van Wirdum Higher priority than Bitcoin.

Sjors Provoost Than trying to fix that particular issue with SegWit rules.

Aaron van Wirdum In case it wasn't clear this also never happened, and it's not plausible to ever become a real problem because like you said we would need a very long reorg etc etc. So these were the hypothetical hardforks that were never actually triggered and therefore arguably shouldn't be considered hardfork at all. Then we get to the implicit consensus change implicit hard fork so which was essentially a bug but which did trigger a hard fork that's the Have we discussed this on our episode?

Sjors Provoost Yeah, we brought it up a few times. So basically it differs in database configuration.

Aaron van Wirdum We discussed this on the previous episode where we discussed one of Jameson Lopp's blog posts running, syncing old Bitcoin nodes, I think. So that was episode 55.

Sjors Provoost Yeah, and I think we've covered it earlier too.

Aaron van Wirdum Of dependencies and yeah. So yeah, this was BIP50 where, let's see, Bitcoin Core... 8? Yeah. 8.0. 0.8. It became incompatible with previous versions due to a dependency on the Berkeley DB database. Is that right?

Sjors Provoost Yeah. So I think what happened is the original version of 0.7, et cetera, used Berkeley database and... And it configured the Berkeley database with some limitations. And I think one of the limitations was basically boiled down to a maximum number of transactions that could fit in a block, like 10,000. And then it was Bitcoin Core was upgraded to a new database format that did not come with any of those limitations. So basically, as soon as you produced a block with more than, I think, 10,000 transactions, the old nodes would say, hey, this is not a valid block. And then the new nodes would say, no, it's perfectly fine. And there was never intended to be that type of limit on the number of transactions. It was just a configuration of the database that wasn't thought through well enough that it would have that implication. Or at least as far as we know, because I don't think Satoshi ever documented saying, hey, by the way, this little limit in the database is important.

Aaron van Wirdum Yeah, so this was a bug based on a dependency, essentially. And this one did actually trigger... A hard fork and also an actual chain split. So for a couple of hours, for about five hours, there were two incompatible Bitcoin blockchains.

Sjors Provoost Yeah, exactly. And people actually had to come to consensus very quickly to decide which side to go for.

Aaron van Wirdum Yeah, and the side they went for was the previous blockchain, the non-hard fork blockchain, essentially. So now if you look at the Bitcoin blockchain, there's no trace of a hard fork happening, right? But there was... For a short time, for five hours.

Sjors Provoost So I think the decision was to use the old rules, to keep using the old rules, even though these old rules were accidental, to keep using those accidental rules for a while, but then later on to relax them. And then it turns into one of those potential hard forks where it could have happened, but nobody actually triggered the condition.

Aaron van Wirdum No, they were triggered later. That's what Lopp explains in the blog post. Oh, right. Even pause om dat goed op te zoeken.

Sjors Provoost No, I think you're right.

Aaron van Wirdum It was triggered later, I think.

Sjors Provoost That's right. So, well, it was triggered immediately, but that part of history has been removed. And then, because it was unexpected and people wanted to have some time to regroup and think about what to do about it. But then later on, the rules were relaxed to actually allow basically whatever size, whatever number of transactions would actually fit into the limit of the block. And that eventually ended up happening. So there was a time when if you were still running that old version of the node, you would not have accepted the new blocks. And then you had the choice between either upgrading to the new node version or changing one configuration.

Aaron van Wirdum So why was that never a problem? Was it never a problem because everyone upgraded by the node?

Sjors Provoost No, it was a problem. If you didn't change that configuration, your node would be in trouble. So that's why you had... Some amount of time to do that.

Aaron van Wirdum That was new to me actually I didn't know that.

Sjors Provoost And I don't think it was very long either it's probably a month.

Aaron van Wirdum Yeah it seems like a bit more than a month but um so

Sjors Provoost you you had a month to do the upgrade. That was when the safety net went away. But before somebody actually produced a block that big, it might have been longer. Okay,

Aaron van Wirdum Sjors, the thing is 0.8.0 was released in March. That's when the accidental split happened. And then shortly thereafter, Bitcoin 0.8 .1 was released, which had some virtual limits to prevent the blockchain from splitting. This expired in May. But then the first time it was triggered was in September 2013. But then it only sort of triggered it compared to Bitcoin Core 0.5 nodes and earlier. And then a couple of years later in 2015. It was triggered again, and this time it affected Bitcoin Core 6 and 7 nodes.

Sjors Provoost Yeah, so it turns out there were probably several database changes that were relevant here. But what kind of surprises me in what Lopp found is that, well, so there was a new version of Bitcoin Core release, and it immediately caused problems. Like, it immediately caused a fork. Then some measures were taken, but apparently nothing else happened that could have caused that fork in three years. That's odd because you think that the reason it went wrong is because miners were quite eager to produce bigger blocks that immediately violated those rules. And then they didn't for a while.

Aaron van Wirdum Well, it was triggered twice. So it was triggered once after six months in respect to older Bitcoin nodes, Bitcoin core nodes 0.4 and 5 and earlier. And then three years later to... Bitcoin nodes six and seven, essentially.

Sjors Provoost Yeah, exactly. But the first hard fork event there, or the first forking event, was against the 0.7 nodes. So whatever the rule was that was violated for 0.7 nodes was violated once, immediately after the release, and then only three years later. Right, yeah. So that tells me that maybe miners were extra careful for a while to just stick to the old rules, even though they didn't have to. So maybe miners just didn't upgrade to 0.8.1 for three years. That's possible. They just didn't want that to happen again.

Aaron van Wirdum That makes sense. Anyways, that was the one example that Jameson found for an implicit hard fork.

Sjors Provoost Yeah, so unintentional.

Aaron van Wirdum Yeah, unintentional. Then finally, we get... Well, in fact, it actually... The thing he did was enabling soft forks. So yeah, he was clearly thinking about it.

Sjors Provoost He wanted those new rules. I don't think it was intentional in that he wanted to split the network. But we can get to that.

Aaron van Wirdum And it didn't split the network. Maybe this was back at a time where people weren't even thinking as much about hard forks or soft forks. Is that what you're saying?

Sjors Provoost Yes, but he was thinking about it because this was exactly the same time when he was working on the block size limit decrease, which was a soft fork in which he did in a very careful way. So my guess is that he did want to add this new feature, did probably not realize that it was a hard fork.

Aaron van Wirdum Well, in fact, the thing he did was enabling soft forks. So, yeah, he was clearly thinking about it.

Sjors Provoost Yeah, he wanted the feature. He wanted to enable future soft forks. Exactly. But I don't think he realized he committed a hard fork in the process.

Aaron van Wirdum In doing so, yeah. So the change is the addition of OP_NOP functions.

Sjors Provoost Yes.

Aaron van Wirdum So what are OP_NOP functions?

Sjors Provoost They're awesome. Well, basically, they are codes that do nothing. No operation is what no op stands for. So it's op, no op, essentially. So what would happen is if your Bitcoin Core node sees those instructions, if an old version of Bitcoin Core, say today's version sees OP_NOP, it'll just say, okay, whatever, and moves on with the script. But a new version may actually attach meaning to it and may say, well, it's not necessarily always valid. There may be some rules in which it's not valid. So this makes it easy to have this thing where new nodes have more strict interpretations of the rules than old nodes.

Aaron van Wirdum Yeah, so this is, for example, used in SegWit, I think, Taproot, like these kinds of...

Sjors Provoost No, it's only been used for check, time lock, verify.

Aaron van Wirdum So anyways, what OP_NOP does, if you're an older node, you just ignore it. But if you're a newer node, then potentially you add extra meaning to it. For example, you see a time lock.

Sjors Provoost Yeah. And so where the hard fork aspect comes in here is that if you look at very old nodes, namely before Satoshi introduced these codes, if they would see that in the script, they wouldn't see op-nop, right? So a script is just a series of numbers. Basically, you know, they're bytes. So byte is 8 -bit, so there's 256 possible things that a byte can be. And every one of those things maps to an opcode. So if the byte says 10, or if the byte says 100, then maybe that's OP_NOP, right? So that's how it works. It's called an enum, an enumerator. So you basically say, when I see a number, I'm going to interpret that as a special meaning. The problem was there was no meaning for those values that OP_NOP uses. So if an OP_NOP occurred in a script, The very old node would say, hey, I don't know what this number means. I'm now going to declare the whole script invalid.

Aaron van Wirdum Right. It wouldn't just ignore it. It would just say, I don't know what this is. This cannot be a valid transaction because I don't know what this is.

Sjors Provoost So if you were to run a Bitcoin node before Satoshi introduced these OP_NOPs, then as soon as it did see an OP_NOP, it would think that transaction is invalid, but future nodes would consider it valid. And that would basically fork them off the network.

Aaron van Wirdum Right. So then the next point is when this actually happened. And so as we just mentioned, the first soft fork that actually used this was CLTV. That was the time lock that Peter Todd designed at the time. But apparently it can be found in the blockchain even before that. So even before any OP_NOP code was attributed to anything, there is an example of it in the blockchain, right?

Sjors Provoost Yes, because everybody is free to use OP_NOP whenever they want to in their crazy experiments. It doesn't do anything. But in practice, most of the time, nobody did that. Except one day somebody was experimenting with the design of a different soft fork proposal and actually decided to use this OP_NOP2 in their experiment for this future soft fork. And so that would have caused an actual hard fork event had somebody still run the 0.3.5 or older nodes.

Aaron van Wirdum Yeah, that was actually Luke Jr. Yep, tinkering with BIP17, which was sort of a competitor to...

Sjors Provoost In any case, if you use the Block Explorer, then the Block Explorer will say, oh, this transaction used OP_NOP2. Or sorry, this transaction used OP_CLTV. But of course, OP_CLTV did not exist at the time. Of that transaction because your block explorer probably doesn't know which opcodes existed at which time in the past. So if your block explorer was really smart, it would say, okay, it was this opcode, but back then it had no meaning. So your block explorer really should say it was OP_NOP2 at the time the transaction was made. Yeah, so somebody used, Luke, I guess, used OP_NOP2.

Aaron van Wirdum Luke Jr. is responsible for the first and only sort of real hard fork in Bitcoin's history. That we know of. The first explicit one, let's put it that way.

Sjors Provoost That we know of. There's there may be many more because you'd really have to inspect what the very old Bitcoin core code would do or Bitcoin code would do under circumstances and a lot of changes were made in the beginning.

Aaron van Wirdum Anyways, I think that concludes our overview, right? So yeah, we've discussed five hard forks that never actually triggered, of which some of us, some of them, we were struggling to figure out why they were actually considered hard forks in the first place. And then one implicit hard fork, which was essentially a bug. And then one explicit one, which was the addition of op-nop.

Sjors Provoost That's right. And I guess we could do some philosophy, but I think we've covered enough for now.

Aaron van Wirdum I'm kind of curious to hear your philosophy now.

Sjors Provoost Well, the question is, you know, what do you want to do in the future with hard forks and bug fixes and stuff like that? But I think we can get into that another time.

Aaron van Wirdum Let's get into it, Sjors. We're here now. I'm here now. I'm not in a rush.

Sjors Provoost Well, so yeah. So what was interesting about this OP_NOP hard fork is that it was introduced in version 0.3.6. And that version also contained some sort of emergency fix. And so one of the reasons you want to avoid hardforks is that it forces everybody to upgrade at the same time. But in this case, everybody is upgrading at the same time anyway because there's like a massive bug. And so then the philosophical question or even the governance question is, you know, if you have some hardfork in mind, do you just wait for the next emergency fix and then just do it anyway? Or not, because you could argue against that, of course.

Aaron van Wirdum Yeah, there's something called the hard fork wish list, right? These are changes to the Bitcoin protocol that are assumed to only be possible with a hard fork. And what you're saying is we definitely need to do a hard fork in the future, it looks like, because there's a bug. The time value overflow bug.

Sjors Provoost Yeah, there is a problem, but that's probably only in 2106 that that actually needs to be fixed.

Aaron van Wirdum Right.

Sjors Provoost From what it looks like right now. And so you could say, well...

Aaron van Wirdum Well, it's better to fix it earlier, right?

Sjors Provoost Yeah, so the idea is that... Well, yeah, so that when you're fixing it earlier, you can think about these things, but you could imagine that some emergency problem shows up that we didn't anticipate and that requires a hard fork to fix. Otherwise, all of Bitcoin is completely destroyed.

Aaron van Wirdum So your question, I think, is if we're going to do a hard fork anyways, would it be better to package it together with other hard forks we want to do?

Sjors Provoost That's kind of the point. Right. That's the question. And I think one answer to that could be no. You do not want to sneak in any other hard forks. You definitely don't want to sneak in any other hard forks. I guess you could have a long-standing debate where this hard fork wish list is actually implemented. And ready to go and said like, okay, this works. We're absolutely sure it's safe, but we're not going to deploy it until there is some other emergency. So you could have some agreement like, okay, when some emergency happens that requires a hard fork, shove this other thing in it because that finishes our hard fork wishlist and might as well use an emergency as an opportunity to fix things. But you generally want to be careful about when people have to upgrade, you don't want to trick them into accepting new rules that are not in their interest. Yeah

Aaron van Wirdum I think everyone agrees that a hard fork needs consensus. Just even if you want to you know package it together it still needs consensus.

Sjors Provoost Yeah because otherwise someone else might say okay we're just going to fix this bug but we're not going to do the other hard fork and then you still have a chain split

Aaron van Wirdum so hard fork just needs consensus. Whether you're packaging it or not. I think the tricky thing with a hard fork requiring consensus is that some people don't want a hard fork for the sake of not wanting a hard fork. So it makes it pretty difficult to get consensus on a hard fork ever. But then maybe the packaging thing kind of works because that argument sort of falls apart for the argument that you don't want a hard fork for the sake of it.

Sjors Provoost Right, if you're saying you never want a hard fork for the sake of having a hard fork, Except when it's an emergency, then you could say, well, okay, if there is an emergency one day, here's the extra stuff we'll do as part of dealing with that emergency. Though my guess is if there really is an emergency, there's not going to be time to combine it with anything else.

Aaron van Wirdum Well, in the example that you gave, there's an emergency in 100 years from now, or what is it?

Sjors Provoost Exactly, that's not an emergency. That is basically something we know is going to happen. And so you can debate a hard fork. Long before that moment, you could say well okay we all agree on what the hard fork is going to look like. We're going to deploy it you know in in five years, and then that deployment will be sitting there for 50 years not doing anything, and in 50 years time everybody will have upgraded to something that enforces the new rules.

Aaron van Wirdum Yes the point being if you need a hard fork for sure then it maybe actually does make sense to package things together with that hard fork if they have consensus. With the exception from the people that don't want a hard fork for the sake of it, because their argument will fall apart when you have to do a hard fork. Yeah,

Sjors Provoost so in the case of the 2106 thing, you could say, okay, you know what, in maybe 30 years time, you know, what's that? That's 2050. Maybe we should have a hard fork in place to fix that bug that's only due in 2106. And then we'll add the rest of the hard fork wishlist to it, which will only take effect in 2106, because it's not that urgent. Something like that.

Aaron van Wirdum Right. Okay, I think at this point we're really digressing. So it's time to cut this off.

Sjors Provoost Sounds good.

Aaron van Wirdum Thank you for listening to Bitcoin Explained.