Author: Matt Corallo 2020-01-14 19:42:07
Published on: 2020-01-14T19:42:07+00:00
The discussion being had is centered around how consensus changes should be implemented in Bitcoin to ensure decentralization, technicality, and improvements while allowing everyone to participate. Developers aim to make proposals that benefit Bitcoin users without negatively impacting anyone. The activation strategy focuses on keeping the Bitcoin network in consensus instead of relying on popularity or voting. Two strategies for locking in upgrades have been proposed: 95%+ of hash power signals they've upgraded to software that enforces the changes forever or after a year of deployment without any technical problems, an additional 2.5 years is allowed to ensure all node software is upgraded before locking in the changes.While the BIP 9 process offers a compelling activation path, it also allows for observation and discussion time for any lingering minor objections before flag-day activation. However, having an "out" to avoid activation after a release has been cut with fork activation logic is quite a compelling requirement since it isn't realistic to expect ecosystem players to spend their time interacting with the Bitcoin development community enough to have a deep understanding of upcoming protocol change designs. In case no activation occurs within a year, a six-month quieting period during which the community can analyze and discuss the reasons for no activation is suggested. A simple command-line/bitcoin.conf parameter could enable users to opt into a BIP 8 deployment with a 24-month time-horizon for flag-day activation. However, there is significant disagreement regarding a mandatory signaling period as part of BIP 8 since it doesn't actually accomplish its stated goal of ensuring miners have upgraded. Recent soft-fork design has aimed at minimal ecosystem impact, and causing significant network forks for old clients has the potential to cause real ecosystem risk if the BIP 8 flag day is hit, which endeavors to de-risk the chance that major players are running on un-upgraded nodes. In a Bitcoin Core mailing list, a consensus rule was suggested that would require blocks to signal for activation in the last activation window as a bip8-like activation. While there are two main advantages to this approach, some argue that it is not necessary to have warnings for outdated nodes and that it is easier for users to actively resist an unwanted change. The focus should be on resolving any reasonable technical objections rather than who has the most money/power/hashpower/nodes/reddit-accounts. The timeline of the segwit process was pointed out as taking about 33 months in total, compared to the 24 months spent since taproot was first described in Jan 2018, or the 42 months before flag-day activation in Matt's proposal. Mistakes made during the segwit process were discussed, such as rushing decision making to increase the block size, alternative clients attempting to activate forks without resolving technical problems, and the incompatibility between ASICBoost and segwit going unnoticed prior to activation. However, it is believed that Matt's approach has a good chance of fixing many of these issues while still leaving flexibility to deal with new problems.
Updated on: 2023-05-20T21:28:46.715543+00:00