Trinary Version Signaling for softfork upgrades

Summary:

The key to Bitcoin's continued decentralization as a currency is allowing for a split between users who disagree on the correct rules or if there is inconsistent enforcement of rules. A clean and well-defined split allows both sides to have the best opportunity while minimizing the risk of a split occurring. Softforks are coordinated between users, NOT miners, and miner involvement is only necessary to set the bit in the header, which users coordinate with, and potentially to accelerate activation by protecting upgrade-lagging users.BIP8 LOT=True ensures miners cannot block an upgrade entirely, but they can still slow it down. Eric Voskuil believes that activation without majority hash power does not prevent a split and that soft forks are incompatible unless enforced by majority hash power. Ultimately, the relevant question is how to prevent a split, and activation without majority hash power certainly does not ensure this.To address problems with current binary signaling, a proposal has been made for a new soft fork upgrade mechanism that uses trinary version signaling instead. This allows for three signaling states: actively supporting the change, actively opposing the change, or not signaling at all (the default state). This additional information can lead to releasing non-contentious upgrades much quicker with a lower percentage of miners signaling support.For contentious upgrades, miners who oppose the change are incentivized to update their software to a version that can actively signal opposition to the change. The more opposition there is, the higher the threshold necessary to lock in the upgrade. If no one signals opposition, a 60% threshold should be relatively safe because it is a supermajority amount that is unlikely to change significantly very quickly. This gives an incentive for "lazy" miners to upgrade if they actually oppose the change while allowing these lazy miners to remain lazy without slowing down the soft fork activation much. The proposal recommends discussing new soft fork upgrade mechanisms when there are no pressing soft fork upgrades ready to deploy to avoid delays and contention. The proposal author invites comments and feedback on the mechanism through Github issues or comments.

Updated on: 2023-06-14T23:38:58.390220+00:00