Post by Bitcoin Core developer Matt Corallo on his proposed strategy for "modern soft fork activation"</p>
There are several design options for a soft fork,have shown significant progress in recent times regarding application and future adoption. However, for a number of reasons, the various ways to activate a soft fork have been much less discussed. I would like to revive the discussion on this topic a little.
It seems to me worth starting with once morecommunicate the main goals for both soft forks and methods for activating them. I can probably be missing something here, but some basic requirements are as follows:
- Avoid activating a soft fork if you havesignificant reasonable and reasoned objections. Not being discussed. If someone has a well-established, intelligent use of Bitcoin that works today, there is no clear reason to believe that this should change in the future, and the changes are making this use case much more difficult or eliminating it entirely, then such changes should not be made to the protocol. ... I hope that this is not objectionable to anyone (see also the important caveat in the last point - a point that I am sure everyone will immediately point out).
- Avoid activating the soft fork in a time frame that is notallowing you to expect a high percentage of adoption of changes at the level of full nodes. Note that, as with all node / node arguments, I am referring to the "economically usable" nodes, not the thousand or so observer nodes on Google Cloud and AWS. Changes to the rules - be it a soft or a hard fork - will not make sense if these rules are not applied by the nodes, so activating too soon, making it impossible or unlikely for large-scale adoption of changes by network nodes, does not make any sense, but it can cause unintended side effects.
- You should not (unnecessarily) lose the hashingpower due to non-updated miners. Since the security of Bitcoin is largely ensured by miners, the side effect of the changes in the form of a decrease in the hashing power of the network would be an undesirable weakening of a key parameter of the network's security. Therefore, in recent history, the adoption of soft forks required 95% of the network's hashing power to refresh and signal a willingness to enforce new network rules. In addition, for this reason, none of the relatively recent soft forks have introduced changes that would exclude backward compatibility with mining on a standard Bitcoin Core instance.
- It is advisable to use the pressure of hashingcapacity, where possible, to reduce the risks associated with the upgrade process. One of the main reasons for performing soft forks is that enforcing rules, backed by hashing power, is an elegant way to avoid network splitting during node updates. While there is no point in investing material assets in systems protected by new rules until most of the "economic nodes" apply these rules, support for hashing power allows us to neatly bridge the time gap between activating a soft fork and completely switching to the new rules. If compliance with the new rules is enforced by the vast majority of miners, then attempts to violate these rules do not lead to a significant split in the network, affecting the experience of existing users of the system. Without intending to take advantage of this, it is better to do the upgrade through a hard fork, with the inevitable lengthening of the time that this entails.
- It is necessary to follow the will of the community, outsideindependence from individual or unfounded objections, but never rejecting any reasonable and substantiated counter-argument. In recent history, there have been "objections" to soft forks along the lines of "this is bad because it does not solve another problem that I would like to see a solution to as soon as possible." I think everyone will agree that such objections to the introduction of the proposed changes cannot be called well-reasoned, and we as a community (but never - as developers or any other separate group) should ignore such remarks and move on. Good engineering solutions are not achieved by bundling unrelated functions into one package for the sake of achieving some political goals or without a compelling compromise.
In my opinion, BIP 9 (plus a well thought outsoft fork) quite well corresponds to paragraphs 2-4, and subject to careful execution and meaningful community support, it can also answer the first paragraph. BIP 9 clearly has problems with the fifth point, I think it's pretty obvious.
BIP 8 was promoted as an alternative solution, inmostly as an answer to the problem with point 5. However, if applied naively, points 1, 3 and 4 are likely to fail, and in my opinion, 5 will also fail, because both of these sentences seem to create an impression, a precedent and, perhaps, even actually increase the ability of developers to define system consensus rules. Deploying BIP 8, which more accurately defines community support, as a prerequisite, could probably solve the problem of compliance with paragraphs 1 and 5, although I am not aware of any concrete proposals for implementing such a solution. A significantly longer activation window is likely to allow BIP 8 to comply with points 3 and 4 as well, but solely at the expense of the "unnecessary" and "where possible" clauses.
You may notice that in terms of achievingBIP 8 differs from activation on a predetermined date (flag-day) except that, if activated successfully before the designated date, it looks like BIP 9, but is not guaranteed. In addition, it has the advantageous property that, in the case of faster acceptance by miners, activation can occur before the appointed time, although the need for acceptance by full nodes in this sense also imposes its limitations.
Therefore, to find a balance between the shortcomings of BIP 8 and BIP 9, the following text was included in the discussion section of the Great Consensus Cleanup proposal (with the specification describing the deployment of BIP 9):
Despite some voices in favor of usingother activation methods, we suggest using BIP 9 to ensure that miners are up to date, which is important to enforce new rules and minimize disruptions. While previous BIP 9 soft forks have been politically divisive, this relatively minor fork is a good opportunity to try to revert to BIP 9 to ensure that miners are upgraded prior to activation, which the authors believe is a major challenge. However, if by the expiration of BIP 9 there is a high level of agreement in the community regarding the activation of these rules, and miners have not yet signaled a sufficient level of readiness, then subsequent forced activation on the appointed date may be justified. For this reason, it may be appropriate in the implementation to provide a compatibility option that would enable these rules to be activated on a designated date and without updating.
Ultimately, despite the ratherlimited discussion, I like this model (although I cannot claim that it is only mine - the original proposal came from Greg Maxwell). BIP 9 falls apart only in the case of unfounded objections, for which, naturally, a high bar should be set, given that we must have some level of agreement that the objection is indeed unreasonable (or inappropriate). Although I admit this possibility, I believe that here it is much lower than in previous soft forks, and even if such a scenario is implemented, it only slows down the process, but does not necessarily stop it. Even if it fails, BIP 9, at a minimum, provides valuable data on the community's readiness and commitment to implementing the proposed changes. While we can (and should) learn a lot about the community's willingness to accept the proposed changes through awareness campaigns and open discussion, there is something about the time-bound changes that makes people look at them more closely.
Thus, bringing the discussion back into moreSubject matter, I think that an activation method that would set the correct use case and appropriately take into account the goals described above could look like this:
- Standard deployment of BIP 9 on a one-year timeframe for activation with 95% miners ready.
- If the activation does not occur within a year, a pause is taken for six months, during which the community can analyze and discuss the reasons why the activation did not occur.
- In case it makes sense, a simplea command line change to a parameter in bitcoin.conf, maintained since the initial deployment, will allow users to choose to deploy BIP 8 with a 24 month time horizon to activate on a designated date.
This gives a very long time horizon formore standard activation, while at the same time ensuring the achievement of the goals outlined in paragraph 5, even if in these cases the time horizon must be significantly extended to meet paragraph 3. Development of Bitcoin is not a race to speed. The 42-month wait, if required, ensures that we don't create a negative precedent through careless actions that will have to be regretted later, as Bitcoin continues to grow.