Trinary Version Signaling for softfork upgrades



Summary:

The Bitcoin community has been in a recent controversy over upgrade mechanisms for the taproot upgrade. To address concerns raised by both BIP8 LOT=true and BIP9/BIP8 LOT=false proponents, a proposal has been made to adopt a new approach to solve the problems faced by both sides. The proposal suggests using trinary version signaling rather than binary signaling, which allows for three signaling states: actively support the change, actively oppose the change, or not signaling. This additional information would help release non-contentious upgrades much quicker while ensuring that contentious upgrades require higher thresholds of support signaling if there is active opposition.One potential issue with the proposal is the difficulty in measuring consensus accurately among users. While community discussion and social consensus estimation as well as miner signaling during the actual deployment period are reasonable mechanisms, they are both very rough estimates of user sentiment. Therefore, multiple barriers are necessary for an upgrade, and higher thresholds of success are required. Developers have an incentive to do things right, but it is impossible to determine with certainty what users want.Soft forks are rule changes that are incompatible unless enforced by majority hash power. Without majority hash power support, activation simply means being off on a chain split. Anyone can split off from a chain by changing a rule at any time, so activation without majority hash power enforcement does not ensure preventing a split. The relevant question is how to prevent a split, and activation without majority hash power certainly does not ensure this. Ultimately, getting majority hash power support is necessary.To prevent delays and contention in the future, the author of the proposal, BT, suggests discussing new mechanisms for soft fork upgrades in the Bitcoin community now, before any pressing upgrades are ready to deploy. They encourage comments on the proposal repository or through GitHub issues. This approach would allow miners to remain lazy without slowing down the soft fork activation much.


Updated on: 2023-06-14T23:35:43.313272+00:00