As the BTC Times reported, the implementation of the Schnorr/Taproot consensus rules were merged into the Bitcoin Core repository in October. The next step will be to discuss how the upgrade is to be activated on Bitcoin’s mainnet. This discussion is now taking a step forward, with Bitcoin mining pools taking the lead in signaling their preferred direction.
Schnorr and Taproot are widely seen as important additions to Bitcoin's technology stack.
Schnorr is an alternative algorithm to ECDSA, which is currently used to generate cryptographic signatures. Schnorr signatures would enable the flexible creation and execution of multisignature transactions by combining signatures. This provides added privacy, as multisignature transactions would become indistinguishable from regular Bitcoin transactions.
Taproot is the specific method in which Schnorr signatures will be leveraged to realize a privacy-preserving smart contract solution. It was first proposed by former Blockstream CTO Gregory Maxwell in the Bitcoin-dev mailing list. Since then, several iterations have taken place, leading to the pull request that was eventually merged.
There is no widespread consensus as to how and when Taproot will be activated, but movement can be observed
According to Taproot-Activation, a website launched by Poolin, three large mining pools have announced their support for the upgrade: Poolin, Slush Pool, and BTC.com. According to BTC.com, the three pools collectively manage around 25% of the Bitcoin network's total hash rate.
The pools currently support different activation processes.
A BIP 9 equivalent, which Poolin announced support for, requires a supermajority of 95% of the hash power to activate. If that threshold isn't reached within a year, the upgrade expires. Following the lengthy activation journey for SegWit, BIP 9 has suffered criticism, however, and some parties no longer regard it as an optimal activation method.
Slush Pool has indicated support for BIP 8 instead, which would enforce the activation through a user-activated soft fork (UASF) once a specific deadline is reached, regardless of whether a majority of miners signals support for the upgrade. BIP 8, too, is not without criticism, as on a short timeline, it could potentially trigger a chain split if activation is enforced without sufficient consensus. An updated version of the proposal would allow nodes to be configured for or against enforced activation, the latter of which would somewhat resemble BIP 9.
Modern Soft Fork Activation support comes from BTC.com: in a way a combination of BIP 9 and BIP 8, this proposal would include a miner signaling period, followed by developer evaluation in case the upgrade fails and, if no problem with the upgrade proposal is found, ultimately enforced activation through BIP 8. Criticism of this proposal mostly evolves around the long time period required.
Of note, neither proposal is final at this point, and parameters can be adjusted. Mining pool support, too, is currently not binding, and it remains to be seen which proposal gains the most support.