Published on: 2015-08-03T08:54:27+00:00
A proposal for a "hardfork bit" has been put forward on Github by jl2012. The proposal aims to address concerns faced by users of a fork where a small/near/fluctuating majority of mining power is supported. The sender of the message praises the proposal, stating that it provides a fallback mechanism for economic actors who can make a decision and say "we're doing this". However, there is uncertainty over how the proposal should be classified and what it should be called. Michael Ruddy has asked whether the latest version of the proposal is available on Github or elsewhere for easier collaboration.The receiver of the message discusses the possibility of multiple hardforks sharing the same flag block and how the coinbase message can prevent any potential ambiguity and provide additional information to the warning system of non-upgrading nodes. The receiver suggests that if there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The receiver also explains why the "version 0" idea is not compatible with the version bits voting system and introduces the hardfork bit BIP as an alternative.The possibility of multiple hardforks sharing the same flag block is slim but can happen. To avoid potential ambiguity, the coinbase message provides additional information to the warning system of non-upgrading nodes. If there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The "version 0" idea is not compatible with the version bits voting system, so a hardfork bit BIP was proposed instead. The commit hash of the BIP for the particular hard fork could be used in the coinbase message. This ensures that the BIP cannot specify itself what to put in the coinbase and allows specific hard fork BIPs to be updated without making code changes. The coinbase message is used to guard against one or more hard forks piggy-backing on another's flag block and to have a nicer message in the alerting system. A version 0 or a >1MB block proposal was also suggested for a block size limit hard fork. However, the >1MB flag block creates DoS banning problems, so it is not as appealing as a version 0 or this hard fork bit proposal. A version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. This is because we'd want to enforce the rules of the previous soft forks that had been locked in. Other than that, the version 0 idea seems pretty similar to the hard fork bit proposal because you need more context than just the block itself to determine if it's a valid flag block. These reasons were part of why the hard fork bit proposal was progressed towards.The proposal for the hard fork bit mechanism is being discussed and refined among the developers. One of the points to consider is how to include BIP-GIT-HASH of the canonical BIP on Github in the coinbase, but it is not known until the code is written. Using the commit hash of the BIP solves this issue, as the BIP cannot specify what to put in the coinbase. The proposal suggests that the hard fork bit allows BIP authors to specify a unique value within a 20-byte limit or use "BIP" in case of small coinbases or to avoid duplicate values. This proposal aims to prevent hard forks from piggy-backing on another's flag block without prior collaboration and to have a nicer message in the alerting system. Another proposal alongside this one involves using version 0 or even >1MB block in the specific case of a block size limit hard fork. However, the >1MB flag block would create DoS banning problems. It also means that older nodes do not have the chance to notice a fork is happening as they would with a version 0 or the hard fork bit proposal. The version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. While these proposals are similar, the hard fork bit proposal has more context than just the block itself to determine if it's a valid flag block.The message is a response to an inquiry about the situation where a group of miners suddenly switch their support, for example not intending to back new rules. The writer suggests that miners may be economically rational and will switch if there is a large decrease in difficulty on the original chain without a corresponding decrease in token value. The message cautions against assuming that all miners will continue to support the side they initially signaled, as they are only invested in the chain they mine for a short time until coinbase maturity. If both sides of a fork retain value, mining will redistribute itself in terms of short term profitability at every difficulty adjustment, regardless of initial signaled support for the fork.
Updated on: 2023-08-01T14:34:44.209378+00:00