Author: Michael Ruddy 2015-08-01 13:05:28
Published on: 2015-08-01T13:05:28+00:00
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.
Updated on: 2023-06-10T03:50:42.994421+00:00