The original article was published in January 2020, on the eve of determining the activation method for the Taproot upgrade. This article was initially published in the Bitcoin-dev mailing list, a discussion space targeting technical readers. However, it is being republished here because a broad audience is interested in this topic. The requirements and goals of Soft Fork activation methods are particularly compelling. Recently, many Soft Fork proposals have made good progress in implementation and adoption. However, for many reasons, the activation methods have not been extensively discussed. I intentionally want to restart the discussion here. Before beginning, it seems worthwhile to review the goals of Soft Fork proposals and their activation methods. I may omit some, but here are the basic requirements: 1) Avoid activation when facing significant, reasonable, and direct opposition. If there is a widely adopted, reasonable Bitcoin usage that is currently valid, and there is no reason to believe it would not continue to be used in the future even without changes, and a change would make this usage no longer possible or significantly increase its difficulty, then such a change should not occur. I hope this point will not provoke opposition (the last point presents an important caveat that everyone would immediately point out). 2) Avoid activation within a timeframe where it is impossible to achieve adoption by a high percentage of nodes. As with all arguments about "nodes," I want to point out that here, "nodes" means "economically relevant" nodes, not thousands of spy nodes on Google Cloud and AWS. If there are no nodes to enforce the rules, a rule change is meaningless, whether it takes the form of a Soft Fork, Hard Fork, or neither. So, activating within a timeframe that cannot achieve widespread node adoption has no value and may lead to unexpected side effects. 3) Do not (unnecessarily) prevent miners without upgrades from providing computing power. Because part of Bitcoin's security comes from miners, if a rule change's side effect is to reduce network hash rate, this is unnecessarily weakening a key security parameter. This is why, in the most recent Soft Forks, 95% of computing power is required to indicate that they have upgraded and are capable of enforcing new rules. Moreover, this is why recent Soft Fork proposals do not include changes that would disable mining functionality for standard Bitcoin Core instances (i.e., requiring changes dependent on Bitcoin Core's standardized behavior). 4) Use computing power enforcement to eliminate upgrade process risks whenever possible. As a necessary result of the above points, one of our primary reasons for using Soft Forks is that computing power-based rule enforcement is an elegant way to prevent network splits during node upgrades. Although it is unwise to invest significant value in a system protected by new rules before a significant proportion of "economic nodes" begin enforcing them, computing power still allows us to cleverly bridge the time gap between activation time and widespread adoption. By having the absolute majority of miners enforce new rules, attempts to violate the new rules will not lead to restricted network splits or interfere with existing system users. If we are not prepared to leverage this, we should instead execute a Hard Fork, which would necessarily slow down the time steps. 5) Follow community will, disregarding personalized, irrational opposition, but not overriding reasonable opposition. Recently, a form of "opposition" to Soft Forks has emerged: "This proposal is not good because it does not fix another problem I think should be fixed quickly." I do not think anyone would consider this a reasonable objection, and we should stand together as a community (not as developers or a specific group) to ignore such opinions and move forward. "Bundling" unrelated features does not bring wise engineering decisions, only political back-and-forth delays and compromises. I believe BIP 9 (plus a carefully crafted Soft Fork proposal) can very effectively check items 2-4 on the above list; with significant community involvement and careful consideration, it can effectively satisfy item 1. As for item 5, I am sure everyone has noticed that this is where things start to become difficult.Author: Blue Matt
Source: https://bluematt.bitcoin.ninja/2020/01/10/modern-soft-fork-activation/
1) A standard BIP 9 deployment process, with a one-year time window for preparation, requiring 95% of miners to be ready; 2) In cases where activation cannot be achieved within a year, set a six-month silent period for the community to analyze and discuss reasons for non-activation; 3) Under reasonable circumstances, provide a simple command-line command/configuration file parameter in the earliest deployment software release, allowing users to choose a BIP 8 deployment process with a 24-month time window to facilitate signal day activation (meanwhile, the new Bitcoin Core release automatically enables this tag).
This provides a very long time window for a more standard activation method; however, while ensuring that the fifth objective can still be met, the time window needs to be significantly extended to ensure the third objective is satisfied. Developing Bitcoin is not a race. If necessary, waiting 42 months can ensure that we are not establishing a negative precedent that we will regret in the future.
(End)
