10 Jan 2020
This was originally posted on the bitcoin-dev mailing list 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.
12 Sep 2018
This post was originally written for an opinion series marking ten years since the announcement of Bitcoin. It was not published at the time but appears here, without change, in the form it was written in late-2018. It was originally published in Dec, 2022 and has been backdated.
Reflecting back on my almost-8-years of working on Bitcoin, I’m very proud of his far we’ve come in answering some of the biggest questions around viability of trustless financial technologies. We’ve gone from a niche technology valued by only a small handful of geeks to something discussed and debated in international financial publications. Bitcoin itself has moved on from a single software project maintained by one individual to a large ecosystem of startups, projects, and individuals the world over. Still, we must not allow our progress to make us think that we’re guaranteed success, however that may be defined. Cryptocurrency’s many detractors, more often than not, raise legitimate issues, and the space as a whole has some serious soul-searching to do when it comes to the types of projects we prioritize.
The broader cryptocurrency community seems to get mired in so many debates on technical minutia that it becomes easy to lose sight of the bigger picture. After all, cryptocurrency will never compete with systems that more directly utilize the efficiencies that trusted parties provide. Even the costs involved in slightly reducing trust in single third parties introduce massive engineering and user experience tradeoffs that almost always make such systems simply uncompetitive. And yet, the cryptocurrency ecosystem seems hell-bent on compromising its trustless origins to eek out a few multiples in performance or “scalability,” all while remaining orders of magnitude away from the user experience of systems with similar trust models. There are simply no use-cases for a financial system in which three entities must cooperate to seize or freeze assets instead of one, especially when that seizure is ordered by a western government with cross-jurisdictional financial reach.
Instead of attempting to compete with centralized alternatives in the broader market, the cryptocurrency community should focus on places where there simply is no competition. After all, no one outside of cryptocurrency has managed to design a similar financial product without a trusted third party despite over 30 years of trying. If we can execute on this vision, those facing financial censorship or collapsing financial infrastructure at home could finally have an alternative to go to for financial services. Sure, that alternative will never significantly improve on the user experience of more centralized alternatives for most use-cases, but by focusing on markets where trustlessness provides genuine value we can generate real adoption that doesn’t come and go with the latest investment bubble, and broader adoption can come in its own time.
Of course utilizing “blockchain technology” to create fictional decentralization can provide all the features we want to get out of Bitcoin’s decentralization with few of the tradeoffs for quite some time, but the benefits of such regulatory arbitrage are dubious, at best. Regulators have a tendency to move slowly, and it can often take tens of years for them to fully understand the contours of their powers and utilize them to shut down behavior they dislike. However, if a system can be controlled by a handful of entities, it eventually will, and no amount of claims about the value of “decentralization” or jurisdiction hopping will stop that.
In order to focus on adoption, however, we need to move on from asking “how” we can make a blockchain go faster, to asking “why” such a system will likely provide long-term benefits for its users that cannot be more efficiently and better replicated with more centralized alternatives. What is the point of building a “better blockchain” that “scales” by replacing the attempt at decentralized ledger-keeping that Bitcoin’s Proof of Work represents with something that clearly will never be more than a handful of companies or individuals confirming transactions? Ultimately, as capital centralizes in a few hands as it has through all of human history, does a Proof of Stake blockchain provide any value for its users that a cluster of high-performance databases run by the inevitable few entities with the vast majority of the capital couldn’t? Do cats really need to be on a blockchain, or can we instead keep them on a server somewhere that provides an identical public interface so anyone who wishes to display or trade them can build their own application to do so?
It is very easy to be swayed by an argument that, because Bitcoin’s Proof of Work is currently fairly centralized, an alternative system need only be equivalent to be worth consideration. This, however, misses the obvious point that if Bitcoin’s Proof of Work were never going to become more distributed and control-resistant than it is today that we may want to start rethinking the viability of cryptocurrency as a whole. Luckily, we have lots of room left to shift the needle on the control-resistance of Bitcoin’s mining system, but the effectiveness and adoption of such proposals remains one of my the biggest long-term concerns for Bitcoin’s (and cryptocurrency’s) future.
As much as building a future we want to see requires focus, we should obviously also take this opportunity to celebrate how far we’ve come in demonstrating Bitcoin’s resilience. What was once a system endeavoring to be “trustless” while its rules were changed by its founder with little outside input or review, the consensus rules of Bitcoin today are not subject to the whim of any one group alone. Prior to the events of 2017, one might have reasonably concluded that any one of a number of different groups had outright control over the rules which govern all Bitcoin users, be it the diverse community of developers working on key Bitcoin software, Bitcoin’s many miners and pool operators, or the largest cryptocurrency businesses. However, despite the outward chaos that was the activation of Segregated Witness, the failure of each individual group in succession to make changes to the rules without the agreement of others showed a resilience that will be critical to any future in which no group of third parties need be trusted to use Bitcoin.
While the originally-proposed release of SegWit saw strong support from across the development community and Bitcoin’s most vocal users, it was met with apathy from the business community and outright hostility from many miners. Thus, despite the best efforts of many to advocate for the benefits and relative few drawbacks of such a change, the original activation method went largely nowhere. A vocally frustrated group of users pushed for the forced activation of SegWit in the form of BIP 148, despite condemnation from most developers for its hasty nature, further inflaming tensions. Finally, the backroom dealing between miners and businesses that led to Segwit2X turned what was a roaring dumpsterfire into a full-fledged emergency. Only when the design of Segwit2X was amended to be compatible with BIP 148 did the two efforts converge and lead to the activation of SegWit, again in spite of the condemnation of the timeline and lack of consensus of both efforts by much of the development community.
Still, with both developers and vocal users shown to not have unilateral control over Bitcoin, one might have reasonably concluded that a group of business leaders may yet be able to exert control. However, with the failure of the second half of Segwit2X thanks to user, developer, and market pressure it become clear that, at least as of 2017, many diverse groups have the ability to veto changes to the rules that govern all Bitcoin users, and no such group can make changes unilaterally.
While the events of 2017 were in no question formative to the fledgeling governance process of Bitcoin’s consensus rules, even the solace we take in each groups’ failure must not be taken for granted. After all, a large number of new users entered the Bitcoin community after the Twitter brawls that characterized the mid-2017 Bitcoin community. We must ensure that the lessons we all took from the many key events in Bitcoin’s history not be forgotten and be accurately communicated to each new generation of Bitcoin users.
Despite the many headwinds and challenges of focus the cryptocurrency community faces over the coming years, the diversity of interests and maturity that has developed in the community over the past ten years, not to mention its explosive growth, gives me great hope that, as long as we define it correctly, the next ten years may be one of cryptocurrency’s success.