Modern Soft Fork Activation [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2020-01-16T03:46:17+00:00


Summary:

The recent discussion on the activation of soft forks in Bitcoin has brought up various proposals and concerns. Matt Corallo suggested using a BIP 9 process to allow for observation and discussion time before activation, but concerns were raised about the timeline for observation. To address this, it was suggested to delay signaling until a later point release, giving miners extra time while still creating pressure to look at the changes. Another suggestion was to move signaling into the coinbase to strengthen the link between signaling and software update. The main focus of the conversation was implementing consensus changes in a way that benefits Bitcoin users without negatively impacting anyone.The ideal percentage of miners needed to upgrade to new rules was also discussed. While a higher percentage reduces the likelihood of long chains of invalid blocks, achieving a 95% threshold can be challenging. The discussion highlighted the timeline of the segwit process and its mistakes, with the belief that Matt's approach can fix many of these issues. Luke Dashjr argued that BIP 9 has flaws and proposed revising BIP 8 with a mandatory signal after the softfork period. This would address concerns about ambiguity and intentional rejection of the softfork, improving the long-term security of the network hashrate. Although the revision of BIP 8 was temporarily abandoned, it should be resumed now.The conversation also touched on the Taproot process and concerns about potential delays if the 95% readiness threshold for activation is not met. Matt suggested decreasing the threshold to around 80% to prevent malicious attempts to delay activation. Discussions about UASF approaches and potential technical problems were also held. It was clarified that long reorgs were only a possibility for old nodes and not necessarily a problem. Issues regarding p2p network splits were resolved well before activation. The community support for BIP148 and Segwit was similar months before BIP148's activation, and excluding BIP148 as an option based on developer opinions was deemed improper.Matt Corallo proposed a new activation strategy for Bitcoin consensus changes, focusing on decentralization and technicality. The proposal includes a standard BIP 9 deployment with a one-year time horizon for activation and a six-month quieting period for analysis and discussion. Users can opt into a BIP 8 deployment with a 24-month time-horizon for flag-day activation using a command-line/bitcoin.conf parameter. The goal is to ensure the Bitcoin network stays in consensus rather than relying on popularity or voting.Jeremy Rubin proposed a spork protocol upgrade model with certain properties, including avoiding activation in the face of reasonable objections, ensuring high node-level adoption, not losing hashpower to un-upgraded miners, using hashpower enforcement to de-risk upgrades, and following the will of the community without overruling reasonable objections.The activation methods for soft forks have been discussed, and it is necessary to revisit the goals and methods for activation. The requirements are to avoid activation in the face of significant objections, ensure high node-level adoption, avoid losing hashpower, use hashpower enforcement, and follow the will of the community while considering reasonable objections.In summary, the discussion on activation methods for soft forks in Bitcoin has been reopened, with a focus on avoiding activation in the face of significant, reasonable objections. The proposed solution involves a BIP 9 deployment with a one-year time horizon for activation and 95% miner readiness. If no activation occurs within a year, there will be a six-month quieting period for analysis and discussion. Users can then opt into a BIP 8 deployment with a 24-month time horizon for flag-day activation. This approach aims to balance community engagement, miner readiness, and avoiding activation within an inadequate timeframe. Furthermore, the proposal addresses the need to prevent hashpower loss from un-upgraded miners and use hashpower enforcement to de-risk the upgrade process. It emphasizes following the will of the community without overruling any reasonable objections. Overall, the discussion highlights the importance of considering the goals of soft fork activation methods and finding a balance between them to ensure a smooth transition while respecting the will of the community.


Updated on: 2023-08-02T01:45:10.795578+00:00