Author: Jameson Lopp 2017-02-26 17:34:57
Published on: 2017-02-26T17:34:57+00:00
The current activation methods for soft forks, IsSuperMajority and BIP9, have limitations such as requiring trust in hash power to validate the upgrade after activation and miner signaling having a natural veto which can veto upgrades for everyone. Upgrade inertia is also inevitable for widely deployed software. Soft fork rules are enforced by nodes, not miners, and miners can opt-out by not including transactions that use the new soft fork feature but cannot produce blocks that are invalid to the soft fork. A flag day activation could be used instead, where nodes begin enforcement at a predetermined time in the future, allowing miners to choose to not participate in triggering activation without being a veto to the process. Soft forks are entirely optional to use post-activation and relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default. Users can activate a soft fork permissively, where miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned. The BIP9 "versionbits" soft fork activation method is also permissive. A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. A combined approach of a user activated soft fork and BIP9 can leverage the warning systems in BIP9 and offer the option of a faster hash power coordinated activation or activation by flag day.
Updated on: 2023-06-11T21:55:07.773847+00:00