From b233285716733020252b1f34ec8c7ae881b6b0a9 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Sat, 11 May 2024 15:25:25 +0000 Subject: [PATCH] Add old "Modern Soft Fork Activation" ML post --- .../2020-01-10-modern-soft-fork-activation.md | 146 ++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 _posts/2020-01-10-modern-soft-fork-activation.md diff --git a/_posts/2020-01-10-modern-soft-fork-activation.md b/_posts/2020-01-10-modern-soft-fork-activation.md new file mode 100644 index 0000000..09b5817 --- /dev/null +++ b/_posts/2020-01-10-modern-soft-fork-activation.md @@ -0,0 +1,146 @@ +--- +layout: post +title: Modern Soft Fork Activation +--- + +This was originally posted on the [bitcoin-dev mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html) targeting a technical audience bbut is preserved here as it is of more general interest. The requirements and goals of soft fork activation are of particular interest. + +There are a series of soft-fork designs which have recently been making +good progress towards implementation and future adoption. However, for +various reasons, activation methods therefor have gotten limited +discussion. I'd like to reopen that discussion here. + +It is likely worth revisiting the goals both for soft forks and their +activation methods to start. I'm probably missing some, but some basic +requirements: + +1) Avoid activating in the face of significant, reasonable, and directed +objection. Period. If someone has a well-accepted, reasonable use of +Bitcoin that is working today, have no reason to believe wouldn't work +long into the future without a change, and which would be made +impossible or significantly more difficult by a change, that change must +not happen. I certainly hope there is no objection on this point (see +the last point for an important caveat that I'm sure everyone will jump +to point out). + +2) Avoid activating within a timeframe which does not make high +node-level-adoption likely. As with all "node" arguments, I'll note that +I mean "economically-used" nodes, not the thousand or so spy nodes on +Google Cloud and AWS. Rule changes don't make sense without nodes +enforcing them, whether they happen to be a soft fork, hard fork, or a +blue fork, so activating in a reduced timeframe that doesn't allow for +large-scale node adoption doesn't have any value, and may cause other +unintended side effects. + +3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of +Bitcoin's security comes from miners, reducing the hashpower of the +network as a side effect of a rule change is a needless reduction in a +key security parameter of the network. This is why, in recent history, +soft forks required 95% of hashpower to indicate that they have upgraded +and are capable of enforcing the new rules. Further, this is why recent +soft forks have not included changes which would result in a standard +Bitcoin Core instance mining invalid-by-new-rules changes (by relying on +the standardness behavior of Bitcoin Core). + +4) Use hashpower enforcement to de-risk the upgrade process, wherever +possible. As a corollary of the above, one of the primary reasons we use +soft forks is that hashpower-based enforcement of rules is an elegant +way to prevent network splits during the node upgrade process. While it +does not make sense to invest material value in systems protected by new +rules until a significant majority of "economic nodes" is enforcing said +rules, hashpower lets us neatly bridge the gap in time between +activation and then. By having a supermajority of miners enforce the new +rules, attempts at violating the new rules does not result in a +significant network split, disrupting existing users of the system. If +we aren't going to take advantage of this, we should do a hard fork +instead, with the necessarily slow timescale that entails. + +5) Follow the will of the community, irrespective of individuals or +unreasoned objection, but without ever overruling any reasonable +objection. Recent history also includes "objection" to soft forks in the +form of "this is bad because it doesn't fix a different problem I want +fixed ASAP". I don't think anyone would argue this qualifies as a +reasonable objection to a change, and we should be in a place, as a +community (never as developers or purely one group), to ignore such +objections and make forward progress in spite of them. We don't make +good engineering decisions by "bundling" unrelated features together to +enable political football and compromise. + +I think BIP 9 (plus a well-crafted softfork) pretty effectively checks +the boxes for #2-4 here, and when done carefully with lots of community +engagement and measurement, can effectively fulfill #1 as well. #5 is, +as I'm sure everyone is aware, where it starts to fall down pretty hard. + +BIP 8 has been proposed as an alternative, largely in response to issues +with #5. However, a naive deployment of it, rather obviously, completely +fails #1, #3, and #4, and, in my view, fails #5 as well by both giving +an impression of, setting a precedent of, and possibly even in practice +increasing the ability of developers to decide the consensus rules of +the system. A BIP 8 deployment that more accurately measures community +support as a prerequisite could arguably fulfill #1 and #5, though I'm +unaware of any concrete proposals on how to accomplish that. Arguably, a +significantly longer activation window could also allow BIP 8 to fulfill +#3 and #4, but only by exploiting the "needlessly" and "wherever +possible" loopholes. + +You may note that, from the point of view of achieving the critical +goals here, BIP 8 is only different from a flag-day activation in that, +if it takes the "happy-path" of activating before the flag day, it looks +like BIP 9, but isn't guaranteed to. It additionally has the +"nice-to-have" property that activation can occur before the flag-day in +the case of faster miner adoption, though there is a limit of how fast +is useful due to node adoption. + +Thus, to strike a balance between the drawbacks of BIP 8 and BIP 9, the +Great Consensus Cleanup softfork proposal included this text in the +discussion section (with the spec describing a BIP 9 deployment): + +> In spite of some suggestion that other activation methods be used, BIP +> 9 is proposed as ensuring miners have upgraded to enforce new rules is +> an important part of minimizing disruption. While previous BIP 9 soft- +> forks have resulted in political contention, this comparatively- +> unimportant soft-fork provides a good opportunity to attempt to return +> to utilizing BIP 9 to ensure miner upgrade prior to activation, which +> the authors believe is a critical goal. However, if there is broad +> agreement to activate these rules when the BIP 9 expiry time is +> reached, and miners have not yet signaled sufficient level of +> readiness, a later flag-day activation may be merited. For this +> reason, implementations may wish to provide a compatibility option +> which allows flag-day enforcement of these rules without an update. + +Ultimately, through admittedly rather limited discussion, I still like +this model (though I cannot claim it as my own, the original proposal +came from Greg Maxwell). BIP 9 only falls apart in case of unreasonable +objection, which, naturally, should carry a high bar to ignore, given we +have to have some level of agreement that it is, in fact, unreasonable +(or untargeted). While I admit this is a possibility, I both find it +less likely than in previous soft-forks, and even if it is the case, it +only slows down the process, it doesn't necessarily stop it. In the case +that it does fail, BIP 9 process, in fact, provides a good learning +opportunity as to the level of community readiness and desire for a +given change. While we can (and should, and are) learning a lot about +community readiness for, and acceptability of a change through outreach +and discussion, there is something about a change with a timeframe that +forces people to more carefully consider it. + +Thus, as something a bit more concrete, I think an activation method +which sets the right precedent and appropriately considers the above +goals, would be: + +1) a standard BIP 9 deployment with a one-year time horizon for +activation with 95% miner readiness, +2) in the case that no activation occurs within a year, a six month +quieting period during which the community can analyze and discussion +the reasons for no activation and, +3) in the case that it makes sense, a simple command-line/bitcoin.conf +parameter which was supported since the original deployment release +would enable users to opt into a BIP 8 deployment with a 24-month +time-horizon for flag-day activation (as well as a new Bitcoin Core +release enabling the flag universally). + +This provides a very long time horizon for more standard activation, +while still ensuring the goals in #5 are met, even if, in those cases, +the time horizon needs to be significantly extended to meet the goals of +#3. Developing Bitcoin is not a race. If we have to, waiting 42 months +ensures we're not setting a negative precedent that we'll come to regret +as Bitcoin continues to grow. -- 2.39.5