Taproot: What a LOT of drama about its activation!

Taproot is an upgrade to the bitcoin protocol which has been in the pipeline since 2018 and aims to make more complex bitcoin transactions look indistinguishable from simpler ones.

This is needed because at the moment, if you create a transaction with more sophisticated redeem criteria than just “I own the private key associated with the output address” then the transaction is bigger (so costs more in transaction fees to be mined) and these redeem criteria are revealed when the output/s are spent.

Taproot therefore brings some additional privacy and will make transactions cheaper. To read a full breakdown of this upgrade: https://tara-annison.medium.com/what-are-taproot-mast-and-schnorr-signatures-b737dae20681

The “When?” question is actually more complex to answer. That’s because whilst almost 90% of miners are showing support for the proposal there is an ongoing disagreement in the bitcoin core community about how this upgrade is to be rolled out.

To understand the cause of this disagreement we need to travel back to 2017 with the last significant upgrade on the bitcoin network: segregated witness (segwit). This proposal sort to provide an answer to bitcoin’s scaling issues by removing the signature data (called the “witness”) outside of the main block data and therefore allowing more transactions to fit within the 1MB block size cap. However, unlike Taproot which has broad industry support, there was a schism in the community about how to scale the network and whether SegWit was the right option, so the upgrade itself was incredibly contentious.

Despite the scaling philosophy disagreements, the rollout plan for SegWit was decided and required a supermajority (95%) of miners to upgrade before a given block; 477,210. This is referred to as a Miner Activated Soft Fork (MASF). However, in February 2017 a pseudo-anonymous developer (Shaolinfry) posted a proposal for what they called a User Activated Soft Fork (UASF). Their concern was that MASFs gave miners too much power and could allow a miner to prevent SegWit from deploying even with majority hashrate support. As such they called to arms all users running bitcoin nodes to upgrade to SegWit compatible versions ahead of the flag date, with the intention of forcing miners to upgrade early due to the economic majority being on a SegWit compatible version. This raised the very real risk of a chain split with some nodes running SegWit and others not, and temperatures across the industry started to rise. This was eventually resolved with the deployment of BIP91 where a sufficient number of miners upgraded to SegWit ahead of the UASF.

All in all, it was a testing time for the network and community members therein.

It is therefore understandable that bitcoiners are still scarred from this experience and approach the Taproot rollout with trepidation.

So how is Taproot intended to be rolled out?

Similar to the SegWit upgrade there is a majority requirement (90%) and an activation window of 1 year. In and of itself this shouldn’t be problematic with the current miner support at c90%. However, miners saying they will upgrade and miners actually upgrading are two different actions and so the rollout must have a ‘back-up’ plan in case the threshold of hashrate support isn’t met. This is all contained with a parameter called “Lock-in On Timeout (LOT)” which can be set to TRUE or FALSE.

In the case that LOT=FALSE then, assuming less than 90% of miners are signalling for Taproot activation by the end of the year expiry, then the proposal will simply fizzle out and the bitcoin code will not include the Taproot upgrade.

In the case that LOT=TRUE just ahead of the expiry date, any LOT=FALSE blocks would start being rejected and the threshold for the majority would be met to activate the Taproot upgrade.

There is FIERCE debate across bitcoin core developers (the bitcoin core team provide the most commonly run bitcoin software but there are other clients; Knots, Libbitcoin, BItcoinJ etc) about which is the correct default value to set in the version of the bitcoin software which would contain the Taproot upgrade. The main advantage of LOT=TRUE is, like the UASF, it removes the miner veto, and allows for early signalling (e.g it could be the case that miners keep their LOT=FALSE config until the last minute, possibly causing another SegWit scenario). However LOT=FALSE proponents claim that LOT=TRUE is overly coercive and having a default of LOT=FALSE allows users to switch to LOT=TRUE closer to the flag date if needed anyway.

Debate seems to be locked across the too camps with technical and moral arguments given. There are alternate options being floated such as a decreasing threshold approach and even some suggestions that Bitcoin Core should hold their release until after Taproot is enabled through other clients. Personally I float between the arguments for LOT=TRUE and LOT=FALSE as they come through on the bitcoin dev mailing list, both certainly have merit and risks. However with the strong industry support for Taproot I personally think LOT=FALSE would be the safest approach and only in the case that the activation period expires would LOT=TRUE be worth exploring.

Overall, whilst it may seem like a trivial argument for such an important and welcomed upgrade, it does serve as a powerful reminder of bitcoin’s decentralized nature. So whilst consensus can be hard to reach, it demonstrates that bitcoin is outside of any one person, entity or development team’s control.

(All views expressed are the authors own and do not necessarily reflect that of their employer or any associated organisations.)