--- /dev/null
+---
+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.
A popular scheme a number of groups are working on building are “rollups” on bitcoin. These are sidechain systems where the transaction data for the sidechain is embedded in the bitcoin blockchain itself. Because these systems can have arbitrarily expressible smart contracts, they are likely to have the potential for advanced MEV extraction similar to what we see on ethereum today. However, in most cases, such systems do not create MEVil in bitcoin. In most rollup systems there is a single or small group of “sequencers” which select the transactions that enter the rollup as well as their order. Thus, the sequencers have the exclusive ability to extract MEV and bitcoin miners are not able to use their transaction selection or ordering power to influence the rollup‘s transactions.
-Some rollup systems, referred to as “sovereign rollups”, however, give bitcoin miners the ability to directly select and order rollup transactions. This runs substantial risk of creating MEVil, and in fact if we see deployment of large-scale naive sovereign rollups I believe bitcoin may suffer a terrible fate. Still, sovereign rollup developers have a few easy tricks which can substantially reduce MEVil risk. First of all, sovereign rollups can remove the ability for miners to order rollup transactions by randomizing the order keyed using the bitcoin block hash. Thus, for miners to influence the order of rollup transactions they must be willing to fully discard valid bitcoin blocks, forgoing potentially substantial profit. Secondly, sovereign rollup developers can randomize transaction ordering across multiple blocks, ensuring single bitcoin miners cannot censor rollup transactions, further reducing their ability to materially extract MEVil. While this may delay rollup transaction confirmation times somewhat, I’d strongly encourage rollup developers to consider whether there is a genuine material difference between users waiting for six confirmations and users waiting for seven, eight, or nine confirmations.
+Some rollup systems, referred to as “based rollups”, however, give bitcoin miners the ability to directly select and order rollup transactions. This runs substantial risk of creating MEVil, and in fact if we see deployment of large-scale naive based rollups I believe bitcoin may suffer a terrible fate. Still, based rollup developers have a few easy tricks which can substantially reduce MEVil risk. First of all, based rollups can remove the ability for miners to order rollup transactions by randomizing the order keyed using the bitcoin block hash. Thus, for miners to influence the order of rollup transactions they must be willing to fully discard valid bitcoin blocks, forgoing potentially substantial profit. Secondly, based rollup developers can randomize transaction ordering across multiple blocks, ensuring single bitcoin miners cannot censor rollup transactions, further reducing their ability to materially extract MEVil. While this may delay rollup transaction confirmation times somewhat, I’d strongly encourage rollup developers to consider whether there is a genuine material difference between users waiting for six confirmations and users waiting for seven, eight, or nine confirmations.
-I’d also encourage developers, Bitcoiners, and everyone to vote with their feet - if a rollup system introduces material MEVil risk to bitcoin, simply use an alternative system - if you don’t, the utility of that system is going to eventually be ruined by increased bitcoin miner centralization anyway. In this case, centralized and federated rollups are much more clearly safe, and decentralized or sovereign rollups should be carefully considered before using them!
+I’d also encourage developers, Bitcoiners, and everyone to vote with their feet - if a rollup system introduces material MEVil risk to bitcoin, simply use an alternative system - if you don’t, the utility of that system is going to eventually be ruined by increased bitcoin miner centralization anyway. In this case, centralized and federated rollups are much more clearly safe, and based rollups or ones with a "force-inclusion" mechanism should be carefully considered before using them!
Another common example raised as MEV on bitcoin is the inclusion of nonstandard transactions or, more broadly, any transactions which reach a miner outside of the public mempool. While this indeed introduces strong centralization pressure for larger miners to offer this as a service, which is absolutely MEVil, we have not yet seen material demand or revenue from such transactions. Indeed, as mentioned above, miners have an incentive to ensure transactions received via private relay reach the public mempool where possible to allow for public RBF bidding. While there is certainly demand for nonstandard transaction inclusion as a novelty, it is unclear if this market will grow in the long term. Further, Bitcoin Core can, should, and generally does allow any transaction as standard, with restrictions only for transactions representing denial-of-service attacks or when the inclusion of a transaction makes Bitcoin Core unable to accurately calculate competitive block templates. As Bitcoin Core continues to improve, the demand for any nonstandard transactions will continue to decline, thus reducing the profit potential of any MEVil extraction.
projects / blog / commitdiff