This article will discuss Taproot, a proposed upgrade to Bitcoin which will bring many new features. This article will cover all the technical aspects of Taproot, the technologies involved in this upgrade, and how those technologies can benefit bitcoin users.
Table of contents
What is Taproot?
Taproot was first proposed by Bitcoin Core contributor Gregory Maxwell in 2018. Its implementation is still in progress. Without Taproot, these complex transactions (timelock, multisig) takes multiple transactions, therefore easy to deduct. Taproot clocks these complex transactions in a way that looks like a single bitcoin transaction, therefore enhancing Bitcoin privacy.
The Taproot upgrade involves three significant technological changes or concepts to improve bitcoin’s scalability, privacy, and flexibility —
- P2SH
- MAST
- Schnorr signatures
We will discuss all these three concepts technically to know how the Taproot upgrade can benefit bitcoin users.
P2SH (Pay-to-ScriptHash)
A Bitcoin address is a string of alphanumerical characters that a user can share with anyone who wishes to send them BTC. Bitcoin has two major transaction standards: Pay-to-PubKeyHash (P2PKH) and Pay-to-ScriptHash (P2SH).
We will discuss P2SH (Pay To Script Hash) and P2PKH (Pay-To-PubKey Hash). But before jumping on these concepts, first, familiarize with some things about Bitcoin —
- You can spend only UTXOs on the bitcoin network. UTXO stands for Unspent Transaction (TX) Output. It is the amount of digital currency left after a cryptocurrency transaction is executed. For example, you have 10 BTC in your bitcoin wallet, and you want to transfer 5 BTC to your friend. What bitcoin blockchain do here is pretty different. It will spend 10 BTC (whole amount) and transfer 5 BTC to your friend’s wallet and the remaining 5 BTC (10 BTC-5 BTC = 5 BTC) to your wallet. So now, you and your friend both will have 5 BTC as an unspent BTC.
- Bitcoin uses a Script (Lines of code) which is a way to specify conditions to spend the bitcoins or the Unspent Transaction Outputs (UTXOs). It is used as a locking mechanism.
- Bitcoins are locked in a script, and when that script returns true or is satisfied, the bitcoins are unlocked.
- Anyone can send bitcoins to any Bitcoin address; those funds can only be spent if they fulfill certain conditions defined in the script. It governs how the next person can spend the sent bitcoins. When senders include a script in a transaction is called PubKey Script, also known as locking script. The receiver of the sent bitcoins will generate a signature script, also known as an unlocking script, which is a collection of data parameters that satisfy a PubKey Script. Signature scripts are called scriptSig in code.
- In the above example, while sending 5 BTC to your friend, the script can also be included in the transaction. If your friend wants to spend those BTC, he has to generate an unlocking script that satisfies the conditions specified in the locking script.
Pay-to-PubKeyHash (P2PKH)
Pay-to-PubKeyHash is a traditional bitcoin address format. Its address begins with the number 1.
Only the owner of the P2PKH address will able to unlock the PubKey Script and spend sent funds by providing a public key hash and a private key signature. A private key is needed to prove ownership of the public key hash.
As we discussed, the script defines under what conditions, the bitcoins present on the specific address can be spent. When specified conditions are met, also verified by the network, the bitcoins present on that address are unlocked, and you can spend them.
How does it work? — Recipient first generates the PubKey script and shares it with the sender. The sender will append the PubKey script into the transaction while sending BTC. On receiving BTC, if the recipient wants to unlock unspent BTC, he needs to provide a public key hash, a private key signature, and fulfill conditions mentioned in a Pubkey script.
Conditions can be like —
- Minimum 2 signatures are needed to unlock bitcoins.
- Provide a password to unlock.
- Bitcoin will be unlocked after a certain amount of time passed.
These kinds of amazing things can put as conditions to unlock bitcoins.
Senders need to include PubKey Script in transactions while sending bitcoins. Hence, this will increase the size of the transaction and will cost fees around five times more than regular transactions.
Here, Sender has to bear the additional cost. Pay-to-ScriptHash will help to overcome this additional cost charged to the sender.
Pay-to-ScriptHash (P2SH)
Pay To Script Hash (P2SH) overcomes the additional amount charged to the sender and shifts this responsibility (extra fees) to the recipients who actually need to utilize conditions specified in the locking script. Pay-to-ScriptHash bitcoin address begins with the number 3.
In this transaction standard, senders no need to put the long PubKey Scripts in their transactions. Here, the locking script is replaced by a redeem script hash. Redeem script hash derived from the redeem script, which is similar to PubKey Script and contains conditions that the recipient must fulfill before spending unspent output. The sender only has to specify the hash of the redeem script in the transaction. The hash of the script can be translated into standard Bitcoin addresses to which the sender can send the bitcoins without any special effort or extra fee.
When the recipient wants to unlock the coins on this P2SH address, they need to produce the redeem script with the same hash value and include it in the transaction. Hence, the transaction size for the recipient to unlock the unspent amount will increase and will cost more to execute the transaction.
For example, Alice wants to send 10 BTC to Bob. Alice has to append Redeem script hash into a transaction. So first, Bob will send Redeem script to unlock unspent output. Then send a hash of Redeem script to Alice so that Alice can add that hash to the transaction and initiate a transaction. If Bob wants to spend that unspent bitcoin, he has to generate an unlocking script with the same hash value and fulfill the conditions mentioned in a script.
Remember, Alice has to append only the hash of the redeem script instead of the entire script. Hence, Alice doesn’t need to bear the additional fee.
Pay-to-ScriptHash Advantages
- Their cryptographic hash replaces lengthy scripts.
- The sender can put any number of the redeem script hash without knowing what spending conditions are specified in the script.
- It reduced the transaction fee for the sender.
P2SH create data-heavy Bitcoin transactions for the owners of P2SH addresses (Recipients).
MAST (Merklized Abstract Syntax Trees)
MAST stands for Merklized Abstract Syntax Trees.
Why MAST? —If you want to spend bitcoins from the P2SH address, you need to produce the redeem script with the same hash value and include it in the transaction. This can make the transaction size very large if so many conditions are involved in the script. MAST provides a solution for this.
Merklized Abstract Syntax Trees is a combination of Merkle Trees and Abstract Syntax Trees.
Like Pay To Script Hash (P2SH) pays to a script matching the hash, MAST pays to the Merkle root’s hash. MAST trick creates a hash tree of individual scripts (conditions) that are part of a large condition set. A Merkle root is a single hash created by hashing all the conditions.
But how Merkle root and tree formed?
First, all the scripts (conditions) are hashed individually; then, the resulting hashes are again combined with the other nearby hashes to make a set of new hashes again. This process will continue until only one hash will remain, and this is called the Merkle root.
For example, you have four sets of conditions that are first hashed individually, and then two hashes are generated from these four hashes. This generates two more hashes from those two pairs, which are again combined to create the final hash. This is called the Merkle root.
You can also translate this Merkle root into a valid and payable Bitcoin address called a Merklized Bitcoin address. It has several benefits, and the main advantage is the ability to verify an individual script residing anywhere in the Merkle tree without knowing all the individual scripts. This technique is called Merkle Proof. This helps to easily verify a Bitcoin transaction having several conditions.
In MAST, bitcoins are locked into the Merkle tree. Merkle tree will specify all the complex condition which can unlock unspent BTC. And each leaf node specifies a condition. While trying to unlock unspent BTC, you will generate a script that will satisfy any branch of the Merkle tree. Merkel root is enough to check whether the condition is a part of the original condition set. If blockchain finds that script (conditions) are part of this Merkle tree only, blockchain gets to know that the coins were locked in this script and unlock them. Hence, we don’t need to generate and include the whole script to spend unspent BTC. This can help to reduce the size of transactions to spend unspent BTC.
Schnorr Signatures
In cryptography, a Schnorr signature is a digital signature produced by the Schnorr signature algorithm described by Claus Schnorr. It is a digital signature scheme known for its simplicity. It aggregates multiple signatures into only one single signature to optimize the verification and authentication processes. It is advisable to use in the case of Multisig transactions.
As you know, to execute the transaction, you need to sign with your private keys to prove that you are the owner of the BTC present on a particular public key. But in Multisig transactions, you have to provide multiple signatures, which takes up extra space.
For example, 12-of-20 multi-sig transaction is there. Here, 12-of-20 means a minimum of 12 signatures among 20 are required to execute the transaction. While signing transactions, signatures also stored on the block. If we consider one signature is of size 5 bytes, then 12 signatures will use 60(5*12 = 60) bytes memory from the block. If 100 signatures are required, then 500 bytes. This increases memory usage. To resolve this problem, Schnorr Signatures comes into the picture.
To understand Schnorr Signatures, go through the below examples:
- You want to send 1.5 BTC to your friend, and you have 0.5 BTC on three different addresses of your wallet. You will sign three times as you have to send 1.5 BTC from different three wallets, which will increase the size of the transaction and fees. Here, all the three signs were done by you only. So, if the Schnorr signature is enabled on Bitcoin’s blockchain, then your Bitcoin wallet will aggregate the three signatures of yours into one signature, which will be valid to send BTC from all three wallets.
- In the case of MultiSig transactions, if you required 100 signatures each of 5 bytes, the Schnorr signature scheme will reduce these 100 signatures to only one schnorr signature of 64 bytes, and an additional space of 436(5*100 – 64 = 436) bytes will be saved for more transactions.
Bitcoin upgrade — Taproot planned to include the above-discussed concepts for better scalability, privacy, and flexibility.
Bitcoin Taproot: Conclusion
After going through the article on Taproot, here are some points that we could conclude-
- Taproot is a bitcoin upgrade proposed by Bitcoin Core contributor Gregory Maxwell in 2018.
- Taproot clocks these complex transactions (Multisig, Timelock) in a way that looks like a single bitcoin transaction, therefore enhancing Bitcoin privacy.
- The Taproot upgrade involves three major technological concepts — P2SH, MAST, Schnorr signatures.
- Bitcoin uses a Script which is a way to specify conditions to spend the bitcoins or the Unspent Transaction Outputs (UTXOs).
- Pay To Script Hash (P2SH) overcomes the additional amount charged to the sender and shifts this responsibility (extra fees) to the recipients who actually need to utilize conditions specified in the locking script.
- In MAST, bitcoins are locked into the Merkle tree. Merkle tree specifies all the complex condition which can unlock unspent BTC. Merklized Abstract Syntax Trees (MAST) is a proposed addition to Bitcoin that allows for smaller transaction sizes to unlock unspent BTC, one no need to generate a lengthy script. Instead, Merkel root is enough to check whether the small script generated by a recipient is a part of the original condition set.
- Schnorr signature aggregates multiple signatures into only one single signature.
