Those who have been in the cryptocurrency space long enough will remember the SegWit improvement and the drama that surrounded its activation. It was the biggest protocol upgrade Bitcoin has experienced in the last few years.
Segregated Witness allows for more block space by removing unnecessary transaction signature data from the main Bitcoin chain. With the upgrade, the scalability issue was provided with a first important step towards a solution since more block space was made available to allow more transactions to fit within the 1MB block size cap.
Taproot was first proposed by Bitcoin Core developer Greg Maxwell in January 2018 as the second most important step towards a scalability solution. Not only that, but it’s also a massive improvement to Bitcoin transaction privacy and smart contract flexibility.
Smart contracts are rarely associated with Bitcoin and are often referred to as an Ethereum feature. Not only are they an already existing component of the bitcoin blockchain, but they will also play an important role in the future of the leading cryptocurrency.
If implemented without too much drama, in a SegWit fashion, Taproot will be deployed through a typical soft fork, which is not a dramatic chain split but a change to the Bitcoin protocol where only previously valid blocks/transactions are made invalid. Since old nodes recognize the new blocks as valid, a soft fork is forward-compatible.
Bitcoin’s transactions are defined by a programming language called Script, which provides the flexibility to change the parameters of what’s needed to spend Bitcoins, for example timelock releases, multi-signature requirements, a combination of public keys, and others.
A combination of keys and/or multi-signatures can be set up by the users in order to perform the transaction in a more secure and efficient way. However, such a combination, if provided in the traditional method, requires a relevant amount of block space and reveals too much information.
Enters Taproot, which ‘aggregates’ all of the keys and/or multi-signatures into one single dataset, in order to save block space and improve scalability. This and more will be made possible by combining Taproot with a related upgrade called Schnorr signatures. One of the main advantages of Schnorr signatures is that they’re able to take multiple keys inside a complex Bitcoin transaction and produce a single unique signature. This means that the signatures from the multiple parties involved in the transaction can be “aggregated” into a single Schnorr signature. This is known as signature aggregation which saves space and improves scalability.
Being built on a public ledger, one of bitcoin’s most popular criticisms is that it’s too public and does not protect anonymity. Basically, anyone can monitor the transactions that occur on the network and for most, that’s a major concern.
Taproot will increase Bitcoin’s smart contract flexibility while offering more privacy in doing so. This improvement will make even the most complex smart contracts indistinguishable from regular transactions and, as a consequence, more private.
Currently, when the bitcoins are spent, all the conditions necessary to trigger the transaction are publicly revealed. Not only does this make the transaction data-heavy, it’s also bad for privacy because everyone can access the funds’ information on the public blockchain and, for example, what kind of wallet is used. Other than the Schnorr Signatures, another solution that will be integrated with Taproot is MAST. The Merkelized Abstract Syntax Tree (MAST) provides a single hash for all the conditions combined instead of these being individually hashed, which easily reveals the full transaction path.
To sum up, Taproot makes it possible to hide the information that a Bitcoin script ran at all. For example, spending bitcoin using Taproot could make a transaction in a Lightning Network channel, a peer-to-peer transaction, or a sophisticated smart contract become indistinguishable. Monitoring any of these transactions would reveal nothing other than a peer-to-peer transaction.
This results in:
- Reduced amount of data to be transferred and stored on the blockchain.
- More transactions per block (higher TPS rate).
- Lower transaction fees.
Following Bitcoin’s established governance system, Taproot went through the widely accepted Bitcoin Implementation Proposal (BIP), a type of document submitted by Bitcoin Core developers to introduce new improvements or features to the protocol. As of October 2020, Taproot has been merged into the Bitcoin Core library after a pull request was created by Pieter Wuille. For the upgrade to be fully deployed, node operators must adopt Taproot’s new consensus rules.
The activation officially started on 1st May with a three-month speedy trial during which miners who wish to upgrade can signal their support by including special data in the blocks they mine called a “signal bit.” If 90% of the blocks mined during this period include the Taproot signal bit, then the upgrade is “locked-in” for activation in November of this year. Progress can be followed here. The green square boxes on the page indicate the signal bit support and have been used as a symbol by Twitter Bitcoin enthusiasts to also show their support for the upgrade. The new implementation is currently widely backed by miners, with the two largest mining pools Antpool and Poolin also recently joining the support and taking the adoption rate to roughly 60% already. It should not be a problem to reach the required consensus. However, should that not be reached, there would still be two options available as a backup plan:
The first is whether to give individual node operators an option to force activate the upgrade if a supermajority of miners fail to support it before the timeout.
This way, node operators could reject blocks from miners who don’t support the upgrade. This sort of measure (a so-called “user-activated soft fork”) was already successfully used during the SegWit upgrade activation in 2017 thus reinforcing the Bitcoin decentralization feature and depriving miners of the highest governance power while empowering the network users.
The second option is to use a method called LOT(LockinOnTime)=TRUE and LOT(LockinOnTime)=FALSE, where the TRUE indicates an automatic mandate for the upgrade to be implemented even after the timeout height is reached. In this case, any LOT=FALSE blocks would start being rejected and the threshold for the majority would be met to activate the Taproot upgrade. The FALSE lets it fall through completely.
While this may seem like a worthless argument for such an important and welcome upgrade, it does serve as a powerful reminder of bitcoin’s decentralized nature. So whilst consensus may appear hard to reach, it demonstrates that bitcoin is outside of any specific person, entity, or development team’s control.
Undoubtedly, this time around, the Bitcoin community is hoping the upgrade can occur without any of the infamous SegWit drama.
Affiliate: Get a Ledger Nano X for $119 So That Hackers Won’t Steal Your Crypto!