#BIP65 REFERENCE MINER CODE#
There are 5 code changes that I'd categorize as being potential hard forks that never came to fruition.īitcoin v0.2 - Satoshi changed the "best chain" selection logic from the chain with the highest block height to the one with the greatest cumulative proof of work. Theoretical Incompatible Consensus Changes As such, inactive / non-triggered hard fork logic should not count as a hard fork. I posit that for a change to be considered a hard fork it should require that all old client versions will fall out of consensus if they are not updated to understand the new protocol rule. Was it an explicit, intended rule change or an unintended implicit change?.Was it a theoretical change or a practical one that actually triggered?.I further break down these incompatible "hard fork" consensus changes along two axes: The same logic holds true for nearly all of the supposed "hard forks" throughout Bitcoin's history. Did Bitcoin hard fork? I would argue that no, while Bitcoin had the potential to hard fork, it never did. The rule change gets reverted, but the loosened rule itself was never triggered! Despite being "active" for a decade, it was removed over 20 years before it would have ever been enforced. As such, in the year 2032 it is agreed that Bitcoin should switch back to the original block subsidy schedule with 33 halvings going all the way down to 0 satoshis of block subsidy. Say a decade goes by with this rule in place but then the block space market takes off and aggregate transaction fees consistently eclipse the block subsidy, causing Bitcoin proponents to no longer worry about the long term sustainability of paying for the network's thermodynamic security.
Let's say that in the next release of every Bitcoin implementation, the block subsidy algorithm is changed to one that has a tail emission of 0.01 BTC in perpetuity after block height 2,520,000 (roughly 30 years from the time of writing) to ensure that miners always get a reward regardless of demand for block space (which results in transaction fees.) For the sake of argument let's even assume that almost every node on the network updates their code to this new rule, whether due to agreement or ignorance.
The Hard Fork That Isn't This is Bitcoin's block subsidy schedule To demonstrate how a consensus change can simultaneously be a hard fork and yet not be a hard fork, consider the following example. Note that I said " known consensus changes" because it's certainly possible that there have been code changes that affected consensus, but did so in such a way that nobody ever noticed because the right conditions were never hit to create a consensus failure between different nodes.īitMEX's list has 3 events labelled as "hard fork." I myself believe there to be 7 consensus changes that could be argued to be hard forks but will make a case for why most should not be considered as such. Consensus ChangesīitMEX has cataloged 21 known consensus changes throughout the 13 year history of Bitcoin. Hard fork consensus changes within a protocol may or may not create chain splits, further complicating the analysis.Īs a result of recent experiments I've run, I've come to the conclusion that there's a nuanced difference between theoretical incompatibility and practical incompatibility, and the term "hard fork" does not do a good job distinguishing between them. But for the purpose of this post I'm focused on the question of hard forks within the Bitcoin protocol itself. From one standpoint, Bitcoin has been hard forked dozens of times to intentionally create alternative protocols / networks / blockchains that are not Bitcoin. The question of Bitcoin hard forking is complicated to answer because it's somewhat open to interpretation.
#BIP65 REFERENCE MINER UPDATE#
Nearly all of the definitions and visualizations you'll find regarding hard and soft forks refer to consensus changes that either require nodes to update their software in order to stay in consensus, or didn't require a software update to stay in consensus. A hard fork can result in a chain split if any block minters don't update their software, but it's not guaranteed The occurs due to a loosening of the consensus rules on block validity, such that some blocks that would have previously been considered invalid are now considered valid.
What is a hard fork? It's a change to the protocol that is not compatible with older versions that is, older client versions would not accept blocks created by newer client versions, considering them invalid.