Last week, Taproot activation locked-in within the “Speedy Trial” activation parameters. Speedy Trial is often described as a kind of “try-and-see” or “fail-fast” approach to activation. While this is a fair description, it is not how Speedy Trial was designed. I would like to write about how Speedy Trial was designed and why it is the way it is. This article assumes the reader is already familiar with Speedy Trial, other Taproot activation proposals, and Bitcoin soft-fork activation in general.
While there is broad community consensus to deploy Taproot, there was not and there is not broad consensus on the entirety of soft-fork deployments. There is broad consensus that miner assisted activation is preferred if and when it is available. In miner assisted activation, miners signal to indicate that they willing, able, and planning to enforce new consensus rules in accordance to a particular activation plan. The economic majority of users then upgrade their nodes to reject new soft-fork invalid blocks in accordance with the activation plan, which holds the miners to their promise. In turn, when a super-majority of the miners reject soft-fork invalid blocks, that protects the minority of users who have not yet upgraded their nodes. This process elegantly keeps the blockchain unified, preventing soft-fork activation induced reorgs and any fraudulent double-spends that such reorgs might allow.
The issues without consensus surround what to do if the miners are unwilling to volunteer to enforce new consensus rules despite broad community support for a soft-fork. While there is a diverse set of people with a diverse set of opinions surrounding these matters, I found that there were three broad factions representing various concerns. In no particular order, they are as follows.
The “no-miner-veto” faction’s concern is that miners will simply never volunteer to enforce new rules either through laziness or outright malice. Miners are short-term thinkers, the argument goes, and the path of least resistance for miners is simply to do nothing. It only takes a small fraction of such miners to prevent reaching a 95% or 90% signalling threshold.
This faction notes that miner signalling is not a critical part of the activation process. Even without miners volunteering to signal, a clear and committed economic super-majority can still reject soft-fork invalid blocks, and the miners will, at least eventually, learn that the coinbase rewards produced in such invalid blocks are worthless and, eventually, stop mining soft-fork invalid blocks. This faction would generally support a flag day activation, with or without a preceding period of miner assisted activation. They may support a “LOT=true” setting where miner signalling is forced at the end of a miner assisted activation. They would not necessarily oppose a “LOT=false” deployment setting, one in which activation fails upon signalling timeout, because such clients are compatible with “LOT=true” which could be used as a follow-up client or with a configuration flag / alternative client. A successfull forced signalling imposed by “LOT=true” clients would activate those “LOT=false” clients, bringing them along, in a certain limited sense, as part of their economic super-majority.
Some members of this faction believe that a super-majority of economic nodes were already willing to run some mandatory activation client, even without broad consensus for it. I dispute the claim that such a super-majority actually exists. I do not see the evidence that this super-majority exists even though one person keeps claiming that the evidence is all around and is so “obvious” that I must be blind not to see it. I would think that if the evidence is so obvious that it would be easy to compile and present it. I have not seen a such presentation of this “obvious” evidence, but I do seen evidence to the contrary. But that is for another post.
The “devs-do-not-decide” faction’s concern is regarding the appearance of Bitcoin developers deciding the rules of Bitcoin. Of course, developers cannot dictate the rules of Bitcoin simply by virtue of the fact that developers have no power to force anyone to run any new version of Bitcoin software. However this faction is concerned that Bitcoin developers merely appearing to be deciding the rules of Bitcoin may put those developers at risk of lawsuits or other threats from those looking to force a change in the rules of Bitcoins for their own benefit. This faction opposes any flag day or any other forced activation sequence such as “LOT=true”. This faction would be fine with users building their own alternative client for forced activation, or a configuration flag for enabling some kind of forced activation that is not enabled by default. There is a possibility that this faction could be okay with a forced activation attempt after a failed miner assisted activation if developers can demonstrate that a super-majority of users did actively indicate their desire for the soft-fork by observing most nodes being upgrading to a soft-fork supporting node, though this question has not really been explored.
The “no-divergent-consensus-rules” faction is concerned about different users running incompatible consensus rules on the Bitcoin network. Of course, users are not forced to run any particular piece of software, and users can run whatever code they want, compatible or not with other clients. Nonetheless, this group is opposed to activation rules that would, from their perspective, encourage the running of incompatible clients, including clients that are only semi-compatible. This faction opposes adding configuration parameters that changes consensus behaviour. This faction opposes any “LOT=false” client that may encourage other users to deploy a semi-compatible “LOT=true” (see the “no-miner-veto” faction). This faction would accept flag-day activation, as it has no miner signalling that can be abused by a “LOT=true” client. This faction would, in principle, accept a “LOT=true” client since, by itself, it does not encourage clients with alternate incompatible consensus rules. That said, it makes very little sense to deploy a “LOT=true” client without the existence of any other “LOT=false” clients whose activation they would be forcing. (Yes, I am referring to the nonsensical design of a certain Taproot alternate client that allegedly has an economic super-majority that is supposedly supposed to be running it.)
While I am not an expert on the theory of governing by consensus, my understanding is that broad consensus is achieved when all reasonable raised concerns have been addressed. Raised concerns must be technical in nature, so that they at have the possibility of being addressable. There are a couple of ways of dealing with a concern that is raised. Everyone can agree that the concern is valid and work together to find a solution or solutions that address the concern. Alternatively, people can try to argue that the raised concern is not actually an issue. Some may argue the concern raised already exists prior to the new proposal and the proposal does not make it worse, or that the raised concern cannot actually happen for some reason, or otherwise convince the group raising the concern that their concern is not really an issue.
There is a third way of proceeding: One can address a concern without conceding that the concern is valid. This can be done if the concern can be addressed without otherwise harming the proposal. This is particularity useful for concerns about soft-fork activation because activation code is transient in nature and can be removed after activation is buried. It can be far easier to accommodate concerns that you do not find valid than it is to convince those raising the concerns that they are wrong. Speedy Trial is a activation proposal that was designed to fit the constrains imposed by the concerns raised by all three factions. This proposal can be accepted by all factions without anyone conceding that the concerns raised by those other factions are valid concerns. While no one will find Speedy Trial to be an ideal activation scheme, hopefully they all at least find Speedy Trial acceptable.
At first glance, the three factions seem all hopelessly incompatible with each other. The “devs-do-not-decide” faction oppose any sort of flag day or “LOT=true” client. The “no-divergent-consensus-rules” faction opposes “LOT=false” clients because of the existence of the “no-miner-veto” faction that is happy to use any “LOT=false” activation client as leverage and release their own semi-compatible “LOT=true” client. However, a more careful examination of the constrains imposed by the three factions reveals a narrow island of acceptable activation parameters that all three groups can be satisfied with. This island is where Speedy Trial lies.
Speedy Trial’s design is not based on any sort of activation philosophy about failing fast. Speedy Trial is designed to satisfy the constraints of many different activation philosophies, even though those philosophies are themselves at odds with each other. Speedy Trial is a “LOT=false” client. This plainly satisfies the “devs-do-not-decide” requirements. Speedy Trial’s short signaling period is meant to satisfy the “no-divergent-consensus-rules” faction because it is no longer reasonable to produce a “LOT=true” client that would add mandatory signalling to the end of this short signalling period. Mandatory signalling requires a long time interval for the super-majority of clients to upgrade first, much longer than the three months of Speedy Trial’s signaling period. Of course, this does not prevent users from running their own alternative activation client, which we noted before is impossible to prevent, but at least Speedy Trial does nothing to encourage such clients. Speaking of alternative activation clients, the segment of the “no-miner-veto” faction hell-bent on releasing their own activation client without achieving broad consensus (but with their alleged economic super-majority support) is somewhat satisfied in the sense that they can incorporate Speedy Trial activation parameters in a semi-compatible way so that they can have the same signalling start time, and same minimum-activation-height, which keeps their client in consensus in the case where Speedy Trial is successful. While this group views the Speedy Trial attempt as largely worthless, at least Speedy Trial parameters do not obstruct their ability to design a mandatory activation client.
The “no-divergent-consensus-rules” and the “no-miner-veto” factions would likely prefer a flag-day tacked on to the end of Speedy Trial. The “devs-do-not-decide” and the “no-miner-veto” factions may prefer some sort of mandatory activation configuration flag to be included. But each of these “improvements” would violate a constraint that is imposed by some other faction. While no one finds Speedy Trial ideal, Speedy Trial does capture activation parameters that are broadly considered acceptable.
There was a wide range of predictions as to whether miners would likely signal within Speedy Trial’s short activation window. I myself originally though it was unlikely that a 90% signalling threshold would be met through a combination of miner laziness and the fact that some miners have made statements suggesting that they prefer Bitcoin to fail in order to redirect their SHA-256 miners to some other SHA-256 altcoin that they rather support. However, people who actually talked with miners, or otherwise seemed to be more well-informed than I was, indicated that there was very broad support for activating Taproot among miners. I thought it was at least plausible that Speedy Trial could activate Taproot within its short window, which made it worth trying. I do not think I would have taken an even odds bet for Speedy Trial working, but if a bet paid out 2-to-1 I would have probably taken it.
Still, some folks within the “no-miner-veto” faction were very adamant that Speedy Trial would fail. One wrote that Speedy Trial’s failure was “likely” and another said that Speedy Trial would at least teach everyone the “obvious” fact that miners will not signal (in adequate numbers) if they are not forced to. These folks would do themselves a favour by going back to reassess the reasoning that caused them to have such strong beliefs, beliefs that turned out to be so wrong. Perhaps even reexamine other strongly held beliefs they might have that may be similarly wrong. (In Bayesian terms, this processes is called updating one’s priors.)
While I believe that Speedy Trial did achieve broad consensus before being merged, it was not without dissent. Rusty NACKed the Speedy Trail proposal, and I never did come to an understanding of why. I do understand that he prefers not to leave the question of what to do if miners fail to signal unanswered. But I fail to understand how not running Speedy Trial helps resolve this question. Nothing in Speedy Trial prevents people from continuing that discussion. At worst Speedy Trial may demotivate such discussion, but the idea holding back Taproot deployment to force such discussions strikes me as manipulative, so I expect that this is not what Rusty meant. As I stated above, raised concerns must be technical in nature in order for them to be addressable. Having never figured out the technical nature of Rusty’s objection to Speedy Trial, and I was not able to address whatever his objection was. “I prefer we do something else” does not count as a technical objection.
There was another objection in the technical minutia of the chosen Speedy Trial activation parameters where the start and end times of the signaling period were specified in terms of Bitcoin’s MTP time rather than based on height. The decision to use MTP for the signalling period was itself another example of achieving broad consensus by addressing concerns raised. There were concerns about testnet and signet signalling periods, whose alternate networks operate at a variety of different heights. On the other hand, there were concerns about how MTP time could cause the transition points in the activation’s state machine to shift by an entire retargeting period if MTP thresholds end up on the boundary of retargeting period and there if reorgs happen around that boundary. This was solved, not by a virtual coin-flip, as is often alleged, but by addressing both concerns. The MTP concerns are most acute for the final activation transition, while reorgs extending or shrinking the signalling period are not really problematic. On the other hand, testnet and signet concerns are only related to signalling period. These networks can use an minimum-activation-height of 0 since there is no concern about the economic majority needing time to upgrage since there is no economy on these test networks. Thus the solution of minimum-activation being height-based, and the signalling period based on MTP addressed all the concerns.
However there was still an objection raised to this solution. It was alleged that there was already consensus to have everything height based, and that doing anything else would be going against that consensus. This objection, again, had no technical component to it. It was simply a statement that the Speedy Trial proposal does not have consensus because some other thing supposedly already had consensus. Firstly, having consensus around one design does not preclude the possibility that another design also has consensus. Secondly, if there is in fact, no consensus with the proposed solution, then it must be due some unaddressed technical concern. If that is the case, they can simply state what that technical concern is. However no such technical objection was forthcoming. Thirdly, the claim that the height-based activation already had consensus is plainly false based on the fact that above we see that technical concerns do exist regarding testnet and signet activation. You could argue that those raised concerns are not actual problems. Or, instead of arguing, you could build consensus by addressing the raised concerns without conceding that those concerns are valid.
This group of people objecting appear to have no interest in actually building broad consensus by addressing raised concerns that they do not think are valid. Instead, one person lobbed accusations that the testnet and signet arguments were raised in bad-faith in order to somehow undermine this alternate Taproot client. I found those accusations disgusting. Even if I personally do not concede that the testnet/signet issue is an actual problem, I still can recognize that testing and testability are legitimate design considerations. And how exactly does the choice of MTP over height based signaling periods undermine this alternate Taproot client? The alternate client could have easily chosen to incorporate a MTP based signaling period over a height based signaling peroid if being semi-compatible was important to them. If semi-compatibility was not very important to them, well since they allegedly had a super-majority of the economic nodes that would run their nodes, the divergent Speedy Trial design would be Speedy Trial’s problem, not theirs.
I could write much more on the issue of that alternate Taproot client, its nonsensical design, and the lack of evidence for their alleged super-majority of economic users (e.g. 16627 /Satoshi:0.21.1/ nodes versus 21 /Satoshi:0.21.0/withTaproot:0.1/ nodes) but I will have to save that rant for another day.