On taproot activation and consensus changes in Bitcoin

Taproot has been under discussion and development for several years now and has had no credible objections to date as a beneficial improvement to the Bitcoin protocol.

However, the method by which a consensus change is activated is itself a consensus rule change. And so just as it is important to evaluate the safety and consequences of the taproot proposal, it is equally important to evaluate the potential consequences of any proposed activation method to enable taproot.

Thus far I believe there is broad agreement that block signaling-based activation is preferred. Given a starting belief that the Bitcoin community supports taproot and that node operators will eventually upgrade to taproot-enabled software, then having a supermajority of miners enforcing the taproot consensus rules reduces the likelihood that we might see a fork on the network (due to some miners creating blocks that are rejected by taproot-aware nodes, but valid to older nodes). Coupled with careful planning to ensure that miners merely using old software should not accidentally create blocks that are taproot-invalid, this ought to allow for the network to remain in consensus around the time of activation — even if not all Bitcoin users have upgraded.

However there seems to be disagreement over whether the taproot activation methodology should include a “lock-in on timeout” feature (“LOT”), whereby taproot activation would occur at a certain block height, in the event that block signaling failed to coordinate an earlier activation height.

I think our overarching goal should be to keep the network in consensus. The LOT behavior would lock in nodes that upgrade into breaking consensus from nodes that do not upgrade, whether or not miners are enforcing those rules; if too large a fraction of the community is running older software at the point that logic kicks in, we might see the network split. Many commenters have tried to analyze the game theory about what might take place, but it should be clear to everyone that analyses like these are speculative, and we cannot be certain what situation we might be in as the lock-in point nears.

In an environment when we expect block-based activation to proceed in the normal case, I don’t believe we should add this additional network risk as a possible outcome, when trying to deploy a non-critical feature. If activation takes longer than expected despite strong community support for taproot, we will be in the same place we are today, and we would retain the option to revisit taproot activation (potentially with LOT) in the future. While such a scenario could cause taproot to take more time to activate, we’re trying to build Bitcoin to stand the test of time, and potential network disruptions are far more costly to creating that future than new features are beneficial.

For added perspective: Bitcoin developers must take great care to not inadvertently introduce consensus bugs. Over the years I’ve spent working with Bitcoin Core developers and contributing to the project myself, I’ve seen firsthand how important a safety-first mindset is when making or reviewing changes. The software development culture we need to make Bitcoin viable over the long-run is one of careful engineering to avoid even remote technical failures from splitting the network, which in turn might undermine confidence in the idea of decentralized digital currency. And so an approach of using brinksmanship at the social layer to prevent consensus failure seems incompatible with that culture. While Bitcoin’s social layer will always be the backstop of Bitcoin consensus, I think we do well to build safety margins on top, so that we don’t risk consensus failure needlessly.

There has been vigorous discussion on the mailing list and in IRC channels on this, and I don’t believe my critique here is novel. Unlike the taproot proposal itself, this particular activation method has received substantial objections, which I believe to be credible and with merit.

What should the implications of that be?

As developers and the community look for a path forward on activation, I think we should each adopt a mindset of only advocating to deploy software that we each believe has consensus. In this case, it’s clear to me that LOT does not meet that standard, and I would hope that even the most ardent supporters of that approach would agree with that as well.

In the face of objections to a proposed consensus change, the right course of action is to try to find common ground for the whole community to move forward together, rather than advocate that a subset move forward alone. We have seen approaches like that play out in other cryptocurrency communities, and in my view a distinguishing feature of Bitcoin — critical for it to endure — is the culture around maintaining consensus as the highest priority.

When a consensus change is controversial, the only reasonable course of action is to stick with current network rules and make no change. If there is no activation method we can agree on at all, then perhaps that means taproot should not be deployed on the network: that might be a sign that any attempt to change Bitcoin’s consensus rules for non-critical features is too risky for the benefits. I’m not so pessimistic as that myself, as I think that the block signaling approach alone should both be sufficient and have limited enough downside to be worth the risk, when weighed against the benefits to Bitcoin from having taproot activated. But this is certainly an issue on which the whole community should come to agreement.