The discussion on Taproot activation appears to have reached its final stage, with the remaining decision revolving around the activation parameter LOT.
The code for Taproot, a proposed Bitcoin protocol upgrade for compact and privacy-preserving smart contracts, has been included in the most recent version of Bitcoin Core, currently the de-facto reference implementation for the Bitcoin protocol. The only remaining step is for the upgrade to activate on the Bitcoin network.
But as a consensus system without central authority, Bitcoin protocol upgrades can be challenging. If one segment of the network upgrades to a new version of the protocol before another segment does, different nodes might enforce different rules, introducing the risk that the network fractures between them.
A soft fork upgrade, which Taproot is, is backwards compatible to minimize this risk. As long as a majority of miners (by hash power) enforce the new rules, both upgraded and non-upgraded nodes accept their version of the blockchain: upgraded nodes because the new rules are properly enforced, and non-upgraded nodes because none of the legacy rules are being broken.
Several of Bitcoin’s previous soft forks have therefore been deployed by leveraging hash power as a coordination mechanism, which is referred to as a miner activated soft fork, or MASF. Once (usually) 95 percent of newly mined blocks included a bit that signaled readiness, all upgraded nodes would start enforcing the new rules. If this threshold wouldn’t be met within (usually) a year, the upgrade would instead expire.
In 2017, the Segregated Witness (SegWit) MASF got close to expiring; in the midst of a heated scaling debate, miners refused to signal readiness for the upgrade. In response, a grassroots group of users and some developers released a special Bitcoin software client: the BIP 148 client. The BIP 148 client would activate SegWit on a given date even if there was insufficient hash power support to meet the original 95 percent threshold, an upgrade mechanism referred to as a user activated soft fork, or UASF. Right before the SegWit UASF would activate, miners started signaling readiness.
Now, about four years later, the events around SegWit activation have spurred a new discussion on soft fork activation in the context of the Taproot upgrade. This discussion is in a small part about the hash power threshold and duration of the activation period — but these seem to have mostly settled on 90 percent and one year, respectively. (Which the remainder of this article will also assume.)
The last remaining point of contention is about the lock-in on timeout (LOT) parameter, which can be set on either “true” (LOT=true) or “false” (LOT=false).
What Are LOT=true And LOT=false?
The mechanics of both the LOT=true and LOT=false options are straightforward. In either case, miners have a year to activate Taproot through hash power signaling. If within that year 90 percent of hash power signals support for the upgrade, Taproot-ready nodes will start enforcing the new rules.
The difference lies in what happens if, when the year is up, miners have not signaled for activation.
In the case of LOT=false, the activation simply expires, like a regular MASF. At that point, Taproot would not have activated, and nodes continue to use the current Bitcoin protocol without Taproot. A new activation period could then be scheduled, this time presumably using LOT=true.
In the case of LOT=true, the activation wouldn’t expire. Instead, like a UASF, nodes in the final weeks of the activation period start rejecting blocks that don’t signal for Taproot activation. When only blocks that signal readiness for Taproot are accepted, the activation threshold will necessarily be reached, assuming of course that Taproot-signaling blocks are mined at all. (There is actually a little bit more nuance to this process, because a small number of non-signaling blocks would still be allowed, but that’s a technical detail and not very important in the context of this article.)
The main argument in favor of LOT=true, is that LOT=false would give miners a “veto” on the upgrade. They could block Taproot activation by refusing to signal readiness, even when there is broad consensus for the upgrade. During the SegWit activation period, it appeared that this veto was being leveraged by miners in an attempt to influence Bitcoin protocol development.
LOT=false proponents, however, argue that this veto isn’t really a veto at all, since it can be overruled. In the end, miners cannot block Taproot activation, because users can always upgrade to LOT=true clients, even if they initially used LOT=false. This can be done in two main ways. Either, users switch to LOT=true clients before the activation period is over, that is, before the end of the year. Or, as already mentioned, they can wait until the activation period is over, and schedule a new activation period.
Proponents of LOT=true however point out that these two different options to overrule the veto could be another recipe for community conflict. If, say, six months into the activation period miners haven’t signaled support for the upgrade, one segment of users may prefer to deploy LOT=true clients before the year is over, while another segment may prefer to wait until after the first activation period before deploying a new activation mechanism. This would essentially reintroduce the current debate between LOT=false and LOT=true, but this time with only six months to resolve the issue. This is easily avoided, LOT=true proponents figure, by simply not giving miners a (sort of) veto in the first place.
But there are arguments in favor of LOT=false and against LOT=true as well.
For one, LOT=false more closely resembles the activation mechanics of previous soft forks, most of which rolled out fairly well. While the SegWit upgrade wasn’t as smooth, LOT=false proponents argue this was due to exceptional circumstances of the “scaling wars,” which are now behind us. (Some LOT=true proponents however believe that LOT=false might invite such circumstances again.)
Second, given that most mining pools have indicated support for the Taproot upgrade, LOT=false is likely to do the job without it ever coming to a timeout scenario. This makes LOT=true unnecessary. (LOT=true proponents instead argue that stated intentions shouldn’t be a factor in designing a technical upgrade mechanism, and that LOT=true would best align incentives to ensure that miners indeed upgrade before the end of the year.)
Third, in the unlikely scenario that a problem with Taproot is found, LOT=false makes it easy to back out of the upgrade: miners would simply refrain from signaling readiness, and the proposal would expire without requiring users to upgrade their software again. (LOT=true proponents believe Taproot is well reviewed, and shouldn’t be up for activation in the first place if that weren’t the case. And even if a problem is found after all, it should be relatively easy to defuse Taproot activation through technical means.)
Fourth, LOT=true could feed into the perception that Bitcoin Core developers have the power to change the Bitcoin protocol. Since LOT=true would “guarantee” Taproot activation, their code would “force” this change of the protocol rules. This perception could attract unwanted attention towards developers.
This perception would be mostly false, as also pointed out by proponents of LOT=true. In the end, users would need to voluntarily choose to adopt the new Bitcoin Core software. Developers can ship code, but they can’t make users run it. Most LOT=false proponents agree, but argue that the perception of developer power might be there regardless, and that perception alone may be harmful enough — even if wrong.
But probably most importantly, the fifth argument for LOT=false and against LOT=true is that LOT=true could in some scenarios result in an unstable network and perhaps even a split in the blockchain. This could lead to a loss of funds for users and miners, and undermine trust in the Bitcoin project altogether.
LOT=true proponents, however, argue that it’s the other way around, and LOT=false in Bitcoin Core would represent the greater risk of this scenario unfolding.
To understand this discrepancy, let’s look at some scenarios…
What If There Is No Network Consensus On LOT?
If there is consensus on either LOT=true or LOT=false — that is, all nodes on the network use one or the other — the scenarios are straightforward. In either case, Taproot would probably activate during the activation period. If not, the upgrade would activate by the end of the year in the case of LOT=true, and miners would have little choice but to accept this (else they’d mine blocks that the network rejects, and they’d be wasting their hash power). Or, in the case of LOT=false, the proposal would expire, and a new activation period would be deployed, this time presumably using LOT=true. (Unless consensus already shifted to LOT=true before the end of the activation period, in which case Taproot would also activate before the year is over.)
It becomes more complex if there is no consensus on either LOT=true or LOT=false. In the unlikely event that the activation period expires, and one segment of the network runs LOT=true clients while another segment runs LOT=false clients, it comes down to the support for each option. (We’ll ignore a third, but important segment for now: users that run neither LOT=true or LOT=false… more on this group in a bit.)
The first thing to note is that if any majority of miners (by hash power) signals support and uses LOT=true, Taproot is guaranteed to upgrade. These miners would by the end of the activation period start rejecting blocks that don’t signal readiness, and since they’d produce a longer blockchain than the minority of non-signaling miners, and because both LOT=true and LOT=false clients would accept this chain as valid, everyone would accept this Taproot-signaling blockchain and activate the upgrade. In other words, the hash power activation threshold would in the last weeks effectively drop from 90 percent to 51 percent.
But if less than half of all miners use LOT=true and the signaling period expires, the Bitcoin blockchain could “split” between LOT=true and LOT=false nodes. LOT=true nodes would only accept signaling blocks, even if non-signaling blocks make a longer blockchain. They would essentially be on their own “LOT=true chain.” LOT=false nodes, meanwhile, would reject the LOT-true chain in favor of the longer “LOT=false chain.”
The result would be a blockchain fork, and ultimately perhaps two different blockchains, each with their “own” transaction history, and essentially their own coins, potentially with their own exchange rates: a “coin split.” Users of either blockchain might consider their own version the “real Bitcoin.”
Barring further protocol changes on the LOT=false chain, however, the LOT=true chain would in this case have a strong game-theoretic advantage. LOT=true nodes and miners would never accept the LOT=false chain, no matter how much longer it were to become. In a “worst case” scenario, it would remain a minority coin.
LOT=false nodes, in contrast, would accept the LOT=true chain if it ever became the longer chain. They’d then abandon “their own” LOT=false chain, and lose any coins they received or mined on it since the split. In short: LOT=false nodes and miners would risk losing money. Therefore, they’d have a strong incentive to just join the LOT=true chain before this can happen. (Especially since they, presumably, don’t object to the Taproot upgrade itself.)
The incentive to join the LOT=true chain would be particularly strong if most users prefer the LOT=true chain, or more accurately, if this chain would have the “economic majority.” If most of the Bitcoin economy prefers to accept and hold coins on a hypothetical LOT=true chain, these coins should demand a higher price and more transaction fees, which would draw in the most miners. This would in turn ensure that the LOT=true chain becomes the longest and therefore only chain.
Here’s the rub. The incentive to join the LOT=true chain before a potential split to be on the “safe side,” would only have an effect if users and miners are aware of what’s going on to begin with. Anyone who assumed that LOT=false would be the upgrade mechanism and therefore didn’t switch, could still lose money if and when a split occurs and the LOT=false chain is abandoned afterwards.
The same is true for the third segment of users, the segment we ignored so far but is actually important to take into consideration: users that run neither LOT=true or LOT=false. These could for example be users that, for whatever reason, don’t keep up with Bitcoin’s upgrade process at all. Like LOT=false users in this scenario, these unsuspecting users could lose money, arguably through no fault of their own.
LOT=false proponents argue that LOT=true essentially “forces” other users to upgrade, which they consider undesirable, if not downright unethical. LOT=false proponents therefore believe LOT=true should only be used as a last resort, if a MASF fails.
LOT=true proponents counter this by positing that the best way to avoid such damage is to deploy LOT=true in a Bitcoin Core release. They believe some segment of users will run a LOT=true client even if it’s not included in Bitcoin Core, and while this may be a small group, it might be big enough to cause a chain split, and the outcome could be ugly.
Implementing LOT=true in Bitcoin Core would therefore be safer, they argue. Since it’s the most widely used Bitcoin implementation on the network, a Bitcoin Core release with LOT=true would likely guarantee that the economic majority uses LOT=true, ensuring that incentives for miners to activate Taproot would be too strong to ignore, minimizing the risk of a coin-split scenario.
So What Will Actually Happen?
It’s impossible to predict how the discussion around LOT=true and LOT=false will resolve — if it will resolve at all.
As a general principle, the Bitcoin Core development process is guided by rough consensus; contentious code shouldn’t make it into a new release. This is of course very true for protocol upgrades like Taproot, but it is probably equally true for code that activates protocol upgrades. While there appears to be rough consensus for Taproot itself, so far there is no rough consensus for an upgrade mechanism.
Perhaps consensus eventually settles on either LOT=true or LOT=false (or perhaps some other solution, like a configurable option for users to choose between the two). But as long as no rough consensus emerges for either, it’s possible that neither option will be included in Bitcoin Core. The Taproot upgrade would effectively be put on hold, at least temporarily.
Another possibility is that consensus emerges to include LOT=false in Bitcoin Core after all, but only because LOT=true proponents independently release an alternative client with LOT=true. This would resemble how SegWit was activated, with the BIP 148 client serving as the equivalent of a LOT=true client. This would however open the door to some of the coin-split risks described in this article.
It’s also possible (but probably less likely) that neither LOT=true or LOT=false is adopted by Bitcoin Core, but either or both options are included in alternative clients. If enough users switch to such alternative clients — even if these are LOT=false clients — Taproot could activate without Bitcoin Core’s involvement. Bitcoin Core could then release a Taproot-compatible version of its software once the rest of the network has upgraded. (This is similar to how some alternative Bitcoin clients, like Libbitcoin, have historically adopted protocol upgrades.)
Or perhaps, a new possibility will present itself.
Author’s note: Some of the arguments and scenarios described in the article are simplified for the sake of readability. In the event of a chain-split, more factors could affect the outcome, while a lack of consensus on LOT=true or LOT=false could also result in smaller (but still harmful) disturbances than the ones described.
To keep up with the Taproot activation process, the bitcoin-dev mailing list and the #taproot-activation channel on Freenode (IRC) are currently the most relevant discussion channels.
