Taproot Activation And The LOT Debate
The process chosen for activating Taproot is detailed in BIP 8, and it includes a debated option called “lockinontimeout” (LOT).
You’ve probably already heard about Taproot, the new proposed soft-fork upgrade for Bitcoin, which will introduce a new signing algorithm and an enhanced, more private and flexible scripting mechanism.
Now, while Taproot has been discussed for a long time, and its code has already been merged to Bitcoin Core, the actual upgrade has not yet taken place. That is, the changes were not yet activated and enforced by the network. The biggest question still left is how to coordinate the activation.
Coordinating Changes To Bitcoin
Why is coordination so important to get right? Well the way that Bitcoin soft forks work is that they introduce new rules to the consensus protocol, i.e., the rules by which a node decides whether a block is valid or not. This means that, in theory, if a node activates a soft fork alone, it finds itself at risk of rejecting blocks that all of the other nodes still accept, essentially forking itself off to another chain that no miners work on, and no users want to transact on.
Now, if a small portion of the nodes coordinates to activate a soft fork, they will find themselves at the same risk as above. They would still be able to transact with one another, assuming at least some miners will still dedicate work to mining its blocks, but they will lose a large part of the mining power, which will still be working on the un-forked chain, making their own fork less useful — since other nodes will not accept its transactions — and more vulnerable to 51 percent attacks.
It is only when the economic majority (nodes actively used for payment verification) of the network coordinates to enable the soft fork together that miners also find themselves at risk — as not upgrading means they might be working on a block which most users will reject, therefore making them waste resources on trying to get a mining reward which no one will accept.
Still, even when the economic majority of the network nodes has successfully coordinated and activated a change, if a significant portion of the miners insist on not enforcing the new rules and will not activate the soft fork, the risk of losing, at least temporarily, a large portion of the securing hash power, is imminent. The “game theory” makes this the most undesirable outcome for all sides — miners risk losing money by mining blocks that the nodes will reject, and the nodes of the network risk loss of hash power and making their chain more vulnerable to attacks.
Since all sides wish to avoid this scenario, great efforts are invested in coordination, ensuring both nodes and miners are ready and willing to activate a soft fork.
You may recall from the drama of the SegWit soft fork activation, when agreement between large portions of miners and those running nodes couldn’t initially be achieved, how miners had eventually complied with the demands of the network to activate SegWit, under the threat of a user-activated soft fork (UASF) that could cause them heavy losses.
While this was a great live demonstration that the power of Bitcoin ultimately belongs to the users, rather than the miners — whose role is of service providers rather than managers — no one suggests that realizing the UASF threat would be the desirable process. Miners would be losing money making blocks users consider invalid, while the users would lose a large factor of security for a while by rejecting the blocks of the non-upgraded miners.
LOT: Moving Forward With Taproot
Fortunately, the activation of Taproot is not nearly as controversial as that of SegWit, if it is controversial at all, and practically no notable objections have been raised from either the users or miners. Still, it is very important to get this upgrade process right, as to make the transition as safe and harmless to Bitcoin as possible.
The process chosen for the activation of Taproot is one which is detailed in BIP 8 (Bitcoin improvement proposal 8). In short, the process works by setting a required threshold of supermajority (typically around 95 percent) of the miners to signal via special data in the blocks they produce that they have upgraded and are ready to activate the change. If the said threshold is reached, a final period of about two weeks (2,016 blocks, one difficulty adjustment) will start, after which the soft fork will be activated and the new rules enforced. This mechanism also includes an “expiration” option, where if the required threshold was not met after a certain block height was passed, the activation process will be cancelled and considered to have failed.
So far, this mechanism is nearly identical to the one previously used for soft forks that is BIP 9. However, the process of BIP 8 include another possible option, which could be either set to true or false (used or not) called “lockinontimeout” (LOT).
This option, when set to true, will introduce a different path in case the miner signalling threshold was not reached before the expiration time. Instead of failing, lockinontimeout will force the move for activation to go forward — essentially acting as a deadline instead of an expiration date. In this case, the nodes running the activation process will start rejecting any blocks which do not signal readiness for the upgrade. This will force the chain to reach the threshold (as only signaling blocks will be included) and the next difficulty adjustment period will be the “locked in” period — the last before activation. In short, LOT would trigger a user-activated soft fork (UASF) in the case that miners refuse to act, similar to how SegWit was activated.
The Controversy Over LOT By Default
While it was decided that the path for activating Taproot will be the process of BIP 8, the debate over using LOT is still ongoing. A recent discussion held on February 16 suggests that a majority of the Bitcoin Core developers would prefer not to enable the LOT option by default. The main objection for the use of LOT being that if the activation of Taproot really is not controversial, as most indicators suggest, the use of LOT will be unnecessary, while if it does end up being controversial, it should fail rather than be activated. It is further argued that it is the role of the Core developers only to propose changes, but by enabling LOT, at least if they do so by default, they will be taking a more aggressive stance than mere proposing, and will be actively pushing toward the protocol change — which is beyond the scope they should act within.
However, when asked during the meeting if they would insist on their original preference, a slight majority in favor of enabling LOT seemed to form. The main claim for supporting the use of LOT was that Taproot has been thoroughly discussed and approved by the community for a long time, and that there’s no reason to let it fail because a small minority of the miners might simply not bother to upgrade — knowing that no harm will happen to them if they just ignore the activation and let it quietly fail. With LOT, miners will not be able to afford ignoring the change and will be forced to actively act as the users demand. In addition, it is said that if Bitcoin Core itself will not offer the signalling for LOT, someone else will fork its code, enable the option and a large portion of the users (node operators) will move away to the forked software. Needless to say, such a scenario is very probable, as we learned during the SegWit activation process, and will make a risky chain split all the more likely.
It is still unclear which approach will eventually be taken, with developers from both sides insisting on their points quite strongly. But it’s worth stressing that whichever choice ends up in Bitcoin Core, it is not in any sense “binding” for Bitcoin as a network. Bitcoin Core is just an implementation of the code for interacting with the network, and as mentioned above, it is possible for anyone to copy the code, make a change to that setting and offer users a different choice regarding the issue.
For this reason, it is very important for anyone running a node to try and understand the discussion. The Core developers’ decisions are always nothing more than recommendations, while the final decisions are made by each node operator and the code according to which they validate their transactions.
For more follow up on the process and planned schedule for Taproot activation, check out the designated page on the Bitcoin Wiki.
This is a guest post by Ben Kaufman. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
