Add old "Modern Soft Fork Activation" ML post

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 (file)
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.