Author: Tier Nolan 2016-02-07 13:18:52
Published on: 2016-02-07T13:18:52+00:00
The email suggests a specific implementation of the "nuclear option" soft fork, which involves adding fields to header 3 that can be expanded later. This would save having to make the merkle tree a sum tree immediately and allow separate sum-trees for each counter (sigops, block size, tx count, sighash?). The email also recommends having dedicated hard fork and soft fork counters, as well as a field for parallel soft forks. Nodes would react to hard forks by stalling the chain, and the hard fork counter means that the new rules could be that nodes should do that going forward for all new hard forks. If a hard fork happens, transaction processing should be shut down and the user informed. Non-upgraded miners could blacklist the hard forking block and keep mining on their own chain, but users should still be given the option of accepting or rejecting the hard fork.
Updated on: 2023-06-11T03:49:53.659353+00:00