Trinary Version Signaling for softfork upgrades



Summary:

The context delves into the issue of soft forks and their compatibility with miner enforcement. Soft forks are not compatible without miner enforcement, which can lead to a chain split. The largest investment in mining determines censorship resistance, making it an economic decision rather than a political one. However, many developers seem to misunderstand this, leading to confusion among users. The discussion also revolves around the issue of splits between disagreeing users and how splitting can be prevented. Some argue that coordinated action based on mining is necessary, while others argue for a more political process. Ultimately, the only solution is to get majority hash power support, and users decide the rules, not miners or developers. Bitcoin is not a democracy, but rather a market where one votes by trading. Starting a new coin is an option, but it is a gamble that does not always pay off. The recent controversy over upgrade mechanisms for the non-controversial taproot upgrade has led to proposals for new soft fork upgrade mechanisms to solve the problems brought up by both sides. One 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 (neither supporting nor opposing). This approach can result in quicker releases of non-contentious upgrades with a lower percent 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. This gives an incentive for "lazy" miners to upgrade if they actually oppose the change while at the same time allowing these lazy miners to remain lazy without significantly slowing down the soft fork activation.Discussions for new soft fork upgrade mechanisms should take place now when there are no pressing soft fork upgrades ready to deploy, to prevent delaying things and causing contention again like it did with taproot. Feedback on the proposed mechanism is encouraged through comments or GitHub issues on the proposal repository itself.


Updated on: 2023-06-14T23:31:47.883690+00:00