A Technical Analysis of Bitcoin Taproot Upgrade

Bitcoin is all set to undergo a major upgrade this November. The upgrade includes many significant changes in the underlying technology of Bitcoin, as mentioned in 3 BIPs (Bitcoin Improvement Proposals): BIP 340 for Schnorr signatures, Taproot in BIP 341, and Validation of Taproot scripts in BIP 342.

The upgrade, called Taproot, was proposed by a core Bitcoin contributor and co-founder and CTO at Blockstream, Gregory Maxwell in 2018. This aims to improve privacy, efficiency, and Bitcoin scripting methods. Certain new features, being anticipated for a long time, are added like smart contract capabilities, Schnorr signatures, Merkle branches, and new sighash modes. The changes make Bitcoin P2SH transactions more private, avoiding unnecessary attention to high volume transactions from hackers, or maybe regulatory bodies.

It is a soft upgrade that is due in November 2021. Users don’t have to upgrade their wallets. The old nodes and bitcoins in circulation will remain entirely unaffected. But if users choose to not upgrade to Taproot by Nov 12th, 2021, they may become vulnerable to certain attacks.

On June 12th, the upgrade was supported and locked in by 90% of all blocks mined on Bitcoin. To support it, users had to upgrade to the latest Bitcoin Core v 0.21.1. Using a soft fork deployment method, BIP9 and Speedy Trial, the miners and mining pools signaled for their support of the soft fork in their mined blocks, in a 2016 block period (roughly 2 weeks). To lock in for activation, 90% of blocks had to signal. The Speedy Trial was due to end in August, but the community achieved the desired consensus early.

Bitcoin’s softfork Taproot upgrade is now locked-in!!!https://t.co/2ENYz4eLZu#taproot pic.twitter.com/XKdCkO8TuU

— BitMEX Research (@BitMEXResearch) June 12, 2021

Since last year, Bitcoin has drawn a lot of investments from financial institutions and retail investors deeming it fit as a new investable asset class. With the proper implementation of Taproot, the new capabilities to handle smart contracts will draw developers to Bitcoin. Just like funds, the Big corporate firms can move to Bitcoin for smart contracts development rather than using the newbie and less secure blockchains.

Bitcoin could now be used in a wide variety of sectors like DeFi, NFTs, ICOs, and IEOs than just being a financial instrument that will give more utility to Bitcoins. Hopefully, this move will soon contribute to making web 3.0 a reality.

Changes in the following BIPs are included in Taproot:

Schnorr Signatures: BIP-340

Bitcoin is based on Elliptic curve cryptography to ensure its security and privacy. It currently uses Elliptic Curve Digital Signature Algorithm (ECDSA) for signing any transaction.

With the Taproot upgrade, Bitcoin is migrating to use another digital signature scheme called, Schnorr signature for authenticating transactions. It is a more secure and non-malleable signature scheme. ECDSA signatures are malleable, allowing any third party to alter an existing signature into another valid digital signature. 

Privacy in P2SH scripts: Using Schnorr signature, the upgrade replaces P2SH transactions with a general P2PKH transaction. A P2PKH (Pay-to-Public-Key-Hash) script is the basic type of Bitcoin transaction. To spend an output locked by this script, called scriptPubKey, the user has to provide an unlocking script, called scriptSig, which is the public and digital signature using the corresponding private key. A P2SH (Pay-to-Script-Hash) is an advanced script that allows a sender to lock the funds to the hash of a script. The redeem script mentions the spending condition of the funds and requires an unlocking script to spend the output.

The redeem script is only revealed during the spending transaction. At that time, anyone in the network can uncover the entire script and identities involved in it, reducing user privacy.

The script size also grows if more complicated spending conditions are involved. Large scripts take up more space in UTXO space which is a disadvantage for the scalability. This also increases the transaction fees the sender has to pay.

Key aggregation in multi-party transactions: Schnorr signatures are linear. This property allows multiple parties in a transaction to collaborate and produce a single signature valid for the sum of their public keys. Any multi-party transaction specified by a P2SH script can be converted to a simple P2PKH transaction. Multiple signatures can be converted to just a single signature using the key aggregation property of Schnorr signatures. Several public keys can be combined into one that produces only one signature.

From a verifier’s perspective, any N-of-N multi-signature will be no different from ordinary signatures. Each signature is no longer required to be verified, paving the way for faster transaction verification. In the case of an M-of-N multi-signature, using Schnorr, M signatures are aggregated into one signature. The transaction is authorized when a threshold number of public keys and signatures are provided, appearing as a normal P2PKH transaction. The aggregate public key can never be linked back to the participants.

Smart contract capabilities: Schnorr signature also enables layer-2 capabilities on top of Bitcoin protocol enabling capabilities of smart contract development using Scriptless scripts. These are a way to encode smart contracts into digital signatures. This enables smaller, more efficient, more private, and scalable scripts.

Atomic swaps: Atomic swap transactions which use adaptor signatures would also appear as a single-signer transaction making them more private. Atomic swap allows the peer-to-peer exchange of two different tokens on two different blockchain networks without the need for any intermediary. Currently, atomic cross-chain trading transactions are trivially linkable if both blockchains are observed.

With this upgrade, the signature encoding is changed to produce a fixed 64-byte digital signature. Irrespective of the complexity of the script, Schnorr signature takes less room, resulting in smaller-sized transactions, reducing fees.

Taproot: BIP-341

Using Schnorr signatures, Taproot introduces a new way to define output spending conditions in any transaction. It is an implementation of the MAST (Merkelized Abstract Syntax Trees) protocol, which is proposed in BIP-114. It uses a Merkle tree called script tree to encode multiple branches in a script which greatly improves privacy by hiding unexecuted scripts.

P2SH and P2WSH (Pay-2-Witness-Script-Hash) require the redeemer to publish all unexpected branches of the script. P2WSH script is similar to P2SH which supports Segregated Witness(SegWit). Users can choose to spend either using a public key as a regular signature (used in P2PKH) or using a script (used in P2SH or P2WSH). When using MAST, for spending a transaction, users have the option to provide only the script branch they are executing. This reduces the size of the redemption stack. This enables users to write complicated funds redemption conditions that were previously limited by the size of the script.

Using this, developers can now create complex contracts with many different clauses. These conditions are encoded and structured in a Merkle tree. Users only need to reveal the script that he executes in order to unlock the funds locked by the script.

In the current Bitcoin execution, when unlocking a P2SH output, all the conditions to spend the fund are revealed. Using the Merkle tree, it is possible to verify the script even if only the condition that is met is revealed. The MAST structure also does not affect the storage requirements, any number of complex conditions can be included without any additional space.  

Using the Taproot feature, P2PKH and P2SH transactions look similar and indistinguishable.

Tapscript: BIP-342

This improves the signature hashing to validate taproot scripts. It is an upgraded version of Bitcoin’s programming language. It enables the easier addition of new features.

Opcodes used for verification of ECDSA signatures, OP_CHECKSIG and OP_CHECKSIGVERIFY, are modified to verify the newly added Schnorr signatures. Opcodes OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are discontinued. To enable batch verification of signatures, a new opcode OP_CHECKSIGADD is introduced.

The new tapscript OP_SUCCESS opcodes allow introducing new opcodes easier. This hopefully makes it easier to add more useful opcodes to Bitcoin scripts in the future.

Conclusion

The Taproot upgrade is a much-awaited upgrade in the Bitcoin community to extend Bitcoin capabilities and realize its full potential. The layer-2 features will enable more use-cases on Bitcoin and hopefully move the industry towards decentralization. The increased privacy and efficiency in the legacy system will bring in more applications to be realized. Hopefully, the upgrade will bring more usefullness for our Bitcoins.