Bitcoin developers have set a timeline for activating Taproot and Schnorr signature updates. They will start working on the blockchain this July.
During the discussions, Bitcoin developers agreed on a release date and activation schedule for the update and Schnorr signatures. However, stakeholders are still debating the best coordination method to activate the largest Bitcoin update since SegWit.
According to the public IRC discussion, the code for the fully prepared Taproot update will be deployed between March 17th and March 31st or, in case of issues, in April. But actual activation won’t start until July.
If all goes according to plan, then Bitcoin’s “economic majority”, miners and node operators, will be able to upgrade within two weeks of the start of the signaling period. In August 2022, the Taproot activation period will expire. If mining pools representing more than 90% of the Bitcoin hashrate support Taproot before this expiration date, then the Taproot update will be activated. The remaining “economic minority” will be able to renew itself later.
However, developers continue to discuss a scenario in which most pools do not signal support for the update.
Activation mechanisms
Unlike centralized networks, where operators can launch updates at any time and at their discretion, the Bitcoin network is decentralized – updates can only be activated after a consensus has been reached between developers, miners, companies and experienced Bitcoin users.
Taproot and Schnorr signature privacy and scaling updates were added to Bitcoin Core in October 2020. Taproot complements Schnorr signatures and offers a new version of transaction outputs and new options for defining the conditions for spending BTC by users.
In some cases, Taproot can even help restore access to lost coins. Schnorr signatures and Taproot are useful for users with complex spending policies who typically control large amounts of money, such as cryptocurrency exchanges. Taproot is a soft fork, that is, a change that is compatible with previous versions of the protocol, as opposed to a hard fork where the new and old rulesets are not compatible.
The main question in activating Taproot is whether or not node operators should be given the option to force the update to be activated if the vast majority of miners don’t support it before the deadline. This will allow node operators to reject blocks from miners that do not support the upgrade.
Another option is to not enable this feature at all. These Bitcoin Improvement Proposal (BIP) options for forced or non-forced refresh are named BIP8 (true) and BIP8 (false) respectively, also known as LOT = true and LOT = false.
LOT is short for lockinontime, a function that determines if the Taproot is blocked if network-wide activation is not reached when timeoutheight is reached. The parameter (true) automatically requires updating after the activation period has expired, and the parameter (false) allows you to completely cancel it.
Opponents of BIP8 (true) say this aggressive measure is not warranted because Taproot is unlikely to be rejected by the community. According to Bitcoin Core developer Andrew Chow and the miner poll regarding Taproot activation, “The community has already decided to activate the update, so there is no need for LOT = true. Miners are part of the community. ” As a reminder, last November, support for upgrading Taproot with mining pools reached 54%.
Taproot and chain branching
Proponents of BIP8 (true) believe that this is a necessary feature to coordinate the update, which, in the event of problems during activation, could split Bitcoin into incompatible versions.
“LOT = true does not fork the chain. It makes it less likely to happen, ”Luke Dashjr, the main proponent of BIP8 (true), said in a chat.
Dashir’s point of view is supported by other developers, for example, hsjoberg, who noted: “LOT = true ensures that the updated nodes support the operation of a particular chain.” This means that the node operators will require that the Taproot version of Bitcoin be a “real” chain. In theory, this will help avoid forking and help build consensus among the participants.
The developer brg444 wrote that “if LOT = true is triggered, the network will split.” But this is possible only if forced activation took place. Brg444 notes that this is unlikely, as the threat of a network fork would be enough to scare the miners into activating the update before the forced activation takes place.
SegWit ghost
Other developers believe that using intimidation tactics is not the best option.
“I think miners are still suffering from PTSD caused by activating SegWit … They are preemptively defensive, seemingly for no reason. Perhaps they are afraid of a repetition of past events, which now have a low probability, ”wrote Olaoluwa Osuntokun, CTO of Lightning Labs, referring to the miners who initially opposed the activation of SegWit.
If, about six months after the start of activation, the miners do not signal Taproot support, then LOT = true can be encoded after the fact for a forced update. However, it would add one more step to the process, and making this change ex post would be more cumbersome than just including it in the original version of the code. However, some developers think this is a smarter solution.
“LOT = true gives the impression that the developers are imposing changes on the community. While not, it doesn’t look very good. Given that there are not likely to be any activation issues, I would prefer LOT = false to avoid this situation, ”wrote Chow.
The last meeting to discuss Taproot showed that most developers support LOT = false. Only about 100 people participated in the discussion, and many still spoke in favor of LOT = true. However, as developer Darosoir pointed out, “we cannot really measure the ‘community consensus’.
According to the Taproot activation plan, 26 participants in the last meeting voted for LOT = false, and 19 for LOT = true. The rest remained neutral and indicated that any option would suit them. At the same time, some developers stated the need to minimize the complexity of the process in order to get a fuller opinion from other community members.
In fact, before starting to roll out the code in March, the developer had only one question left to answer – whether to include the forced activation option in the original code.
