Author: jl2012 at xbt.hk 2015-08-01 20:23:23
Published on: 2015-08-01T20:23:23+00:00
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 non-upgrading nodes' warning system. 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.
Updated on: 2023-06-10T03:51:28.487835+00:00