The simplest explanation of Taproot

Ladies and gentlemen welcome on board to my channel 🤣

We will be taking off shortly. Please make sure your seat belt is securely fastened, take away every distraction, and let's fly.

N.B: I'd expect that you have a basic understanding of the operations and terminologies associated with Bitcoin.

On November 14th, 2021, precisely at block number 709,632, Bitcoin experienced its most significant technical upgrade since Segwit in 2017, known as Taproot. Taproot, originally proposed by Gregory Maxwell in 2018 and developed by Pieter Wuille alongside other amazing bitcoin developers, became part of Bitcoin's code. This upgrade was designed to improve Bitcoin's security, privacy, and throughput rate while reducing fees and laying a foundation for future upgrades.

Bitcoin has been, to me, one of the most important inventions since the internet's inception. For an invention that is barely 14 years (at the time of writing this article), we have seen so much growth, mass adoption, and enthusiasm toward this particular invention. This has been ever-increasing, year in and year out.

Before we dive into Taproot, it would be great to look at Bitcoin from its transaction's view.

A Bitcoin transaction, in simple terms, is a transfer of bitcoin from one address to another on the blockchain. Bitcoin offers the same level of ease in terms of transactions as it is in the traditional banking system. What it takes is a Bitcoin user inputting the amount they want to send, and the recipient's address in their Bitcoin wallet and press send.

Although a lot happens under the hood, as a user, you should be less concerned about the technicalities or system of operations. But if you have gotten to this point of the article, you are beyond a user, so if we are really going to dig into Taproot, we should discuss how Bitcoin transaction works in practice.

Bitcoin Transaction

For the integrity of the transaction created on the network, Bitcoin makes use of public-key cryptography. Every participant on the Bitcoin network has a pair of keys (public and private). The major difference between them is that while the public is known by everyone who has a copy of the blockchain, which they can use to identify the user, the private key is known only to the user.

When a user creates a wallet, they randomly generate this cryptographic key pair which they use to send or receive Bitcoin. When this user, let's call Mr.A, needs to send 1 BTC to another user (Mr. B), we initially mentioned that all Mr.A needed to do was to input 1BTC (amount) and the address of Mr. B (Read up on Addresses here if you need further explanation), but what then happens is that Mr. A actually signs a message with the transaction details using his private key. This message contains three things: input (Mr. A's Bitcoin that he wants to send from), output (where he is sending to), and amount (how much he wants to send). Once he is done signing the transaction, he then broadcasts it. But unlike traditional banking and some other cryptocurrencies, which operate the account model (a single database record that updates and keeps track of a user's monetary value), Bitcoin operates the UTXO model. The UTXO model is Bitcoin's method for organizing the blockchain ledger such that no coins are spent twice. The fundamental building block of a bitcoin transaction is an unspent transaction output (UTXO).

UTXOs are an indivisible chunk of the bitcoin currency recorded on the blockchain and recognized as currency units by the entire network. Every UTXO on the network is locked to a specific owner. Similar to padlocks and keys, when you lock a padlock, you would need a unique key to be able to unlock it, you would also need an unlocking script (in our case) to be able to unlock UTXOs to spend, and these unlocking scripts are peculiar and unique to users using their private key. So instead of having one single ledger to update the user's balance and spend from, all a user needs to do is to find UTXOs that it can spend from.

So when we say Mr. A sends an amount from his input to Mr. B's address, what really happens is that Mr. A searches through the Bitcoin network to find UTXOs that his private key can unlock. But because your software manages and keeps track of UTXOs that belong to that wallet, it is easier to retrieve. The user then aggregates them till it gets to the amount he wants to send and then sends it to Mr. B's address by creating a new locking script for that UTXO amount, using Mr. B's address to form an unlocking script for the same UTXO, so that only Mr. B can be able to spend that new UTXO. This is why many people call a Bitcoin transaction a transfer of ownership from the sender to the recipient. So Mr. B's address is what is used to create a new locking script, and we mentioned that the private key is what is used to unlock these UTXOs, so what then is the relationship between the user's address and the keys?
Bitcoin wallet addresses are basically a hash of the wallet's public key, and a public key matches a private key.
Formerly, Bitcoin transactions were made to the public key, a term called P2PK, but for superior security and convenience, amongst other concerns, new improvements were made; afterwards Bitcoins were then sent to a hash of the public key called addresses. Addresses are derived from public keys using a one-way hash function so that you can only get an address from a public key, but the reverse isn't feasible. There are different address formats available, Pay-to-Public-Key hash (P2PKH), Pay-to-Script Hash (P2SH), etc.

So, in summary, Mr. A, while sending Bitcoin to Mr. B, scans the network for UTXOs he can spend, unlocks it with his private key, aggregates the amount he wants to send to Mr. B, creates a locking script with Mr. B's address (which in turn is Mr. B's public key), from which Mr. B can now unlock using his private key together with the public key to either spend or send it to Mr. C. (Chain of transfer of ownership)

Bitcoin traditionally uses ECDSA (Elliptic Curve Digital Signature Algorithm), which is an application of public-key cryptography to authenticate transactions.
ECDSA utilizes ECC (Elliptic Curve Cryptography), which basically is a type of cryptography that uses elliptic curves to sign data such that the authenticity of the signed data is easily verifiable but nearly impossible to forge without a signing key.

So Taproot...

The Taproot upgrade consists of three (3) distinct Bitcoin Improvement Proposals (BIPs):

1. Taproot

2. Tapscript

3. Schnorr SIgnatures

While we look at them individually and the improvements that they offer, it is good to know that Taproot aims to bring several benefits to Bitcoin users, such as enhanced transaction privacy as well as lower transaction fees. Taproot would also enable Bitcoin to execute more complex transactions and potentially pave way for new features to be introduced based on all of Taproot's advantages.

Schnorr Signature (BIP 340)

The Bitcoin system, or in general any cryptographic currency, has to revolve around the concept of digital signatures in order to enable the transfer of coins.
There are many varieties of Digital signature algorithms available, with each having its advantages and disadvantages. Prior to the Taproot upgrade, Bitcoin used the algorithm known as ECDSA (Elliptic Curve Digital Signature Algorithm). which utilizes Elliptic Curve Cryptography (same as Schnorr).

In our transaction example above, we see that only Mr. A's signature is needed to send funds to Mr. B. This is very common in Bitcoin transactions; in many instances, only a single signature is necessary to sign a message or transaction. However, this is not the case in all situations. Bitcoin has the capability to act as what we call a joint account in traditional banking, where multiple signers have to exist in order to spend some coins, a term called multi-signature in Bitcoin. Most multi-signature schemes generally require m-of-n signatures (where n is considered the total number of individual participants and m is the minimum number required of the total before the transaction will be considered valid).

Basic transactions in Bitcoin involve sending Bitcoin to a public key (Pay-To-Public-Key-Hash), but unlike P2PKH, we have Pay-To-Script-Hash (P2SH), which is a Bitcoin script used for multi-signature (its usage is not limited to this). P2SH allows for the spending of Bitcoin based on the satisfaction of the script whose hash is specified within the transaction.

There are drawbacks to P2SH: one of them is that all the possible conditions that could have been met, including the conditions that weren't met to spend the coins, must be revealed. Using a relatable instance, you want to go to W-Bar, and to enter the bar, you need to have an ID with a picture and name on it so as to ensure proof of who you are. But the ID that you possess contains some extra information, such as your age, and your mobile number, maybe your house address, which literally isn't a requirement to enter the bar, but because you have to present an ID, automatically you have given some extra personal information about you to a complete stranger, making you vulnerable to the unknown. This creates potential privacy issues. People can see all the possible ways the conditions could have been met, what kind of wallets were used, etc.
Another drawback is that, as public keys attached to the Bitcoin increase or as the conditions required to spend the coin increase, computation, and verification become data heavy. Also, another drawback is that it was easy to differentiate between a basic Bitcoin transaction and a Bitcoin multi-signature transaction.

With all these drawbacks, this is where Schnorr's signature comes in.

The most pointed-out benefit of Schnorr signatures over ECDSA is that it makes multi-signature and single-signature transactions indistinguishable on the blockchain. With Schnorr, it is impossible for an outside observer to tell the difference. How so? with Schnorr, the signatures of the different signees required for multi-signature are aggregated together, producing a single public key and then jointly signed with one signature, rather than each required m (from m of n discussed earlier) publishing and signing its signature separately on the blockchain. This enhances the scalability and privacy of the Bitcoin network. This one single improvement paves way for other advantages, for example, it gives way to linear verification. By aggregating public keys into a single key, Schnorr literally shortens the transaction verification process, being that the network only needs to verify one key (an aggregate of all the other keys) rather than multiple keys. This is a concept known as batch validation.
One other benefit to point out is that schnorr signatures and public keys are smaller than ECDSA signatures and public keys, respectively. Schnorr signature, for instance, is fixed in size at 64 bytes, while the existing ECDSA signature is around 70-72 bytes. This lightness allows the network to free up block space and scale more efficiently. As a result, users pay fewer fees for transactions. With more available block space, we see that we have more block transaction validation occurs and less network congestion. So we see Schnorr's signature saving the day by saving space, verification time, and transaction fees, among others.

Taproot (BIP 341)

The motivation behind Taproot, according to BIP341, is to improve privacy, efficiency, and flexibility of Bitcoin's scripting capabilities without adding new security assumptions. BIP 341 brought about the introduction of a new output type (address) called Pay-to-Taproot (P2TR) which basically allows for the inclusion of Schnorr's signature, which aims to improve privacy, efficiency, and flexibility of the network. As we have mentioned, using the previous transaction types, such as P2PKH and P2SH, involves revealing all the conditions of the script (including the not-so-compulsory one), and that is something that has significantly reduced privacy. We gave an example in the earlier section, where one needed an ID to access a bar, but the ID in the person's possession contains some other personal information that is not necessary but is, by default, imprinted on the ID. What if we had a way to show this ID and show off the necessary information (such as the picture, and full name), leaving out the unnecessary ones? This is what this BIP (Taproot) aims to fix.
For us to efficiently discuss this BIP, there is another concept I need to introduce, which is MAST (Merklized Alternative Script Trees).

MAST

Merkle Tree is a very important, and interesting concept in the Bitcoin Network. It basically involves complexity reduction, whereby users hash scripts in pairs to get a shorter unique identifier for that particular pair. Just like binary trees, Merkle tree involves hashing in twos from the ground up. It goes on and on until one identifier is what is left, called the Merkle root.

Merkle tree is majorly linked with SPV nodes. Transactions are hash and hashed in the tree format until the Merkle root is formed. The Merkle tree can be used to confirm the existence of a transaction. To prove that a transaction is in the tree, a full node needs to provide to the other node the set of hashes that would be combined with that transaction to create the Merkle Root. This is much less data than providing all the transactions in a block. Without this mechanism, an SPV would not be able to interact with the blockchain, this is why I mentioned that the Merkle tree is majorly linked with SPV nodes.

MAST is an extension of the Merkle tree concept, except that it is applied to advanced transaction types or conditional payments. Similarly, MAST allows spending conditions to be structured in a Merkle tree. Pre-MAST, the spender needed to show the blockchain entirety of potential conditions to spend a transaction, but with MAST, only the conditions that are met are revealed at the Merkle root level. The Merkle root and path are used to verify that the condition lies in the Merkle tree while keeping the rest of the conditions in the tree hashed and hidden.

Using the W-bar example we stated above, where we were a little withdrawn because our ID had other personal information outside of our name and picture; now, we can then proceed to walk into the bar, showing off the same ID with full confidence that the bouncer would only be able to view our picture, read our names, but would not be able to read any other information.

This solution reduces the amount of data revealed on-chain. Aside from the privacy benefit, MAST can also create smaller transaction sizes seeing that it follows the Merkle principle. Non-MAST transaction sizes increase in cost linearly, while MAST transaction sizes increase only logarithmically. Thus reducing the data load, and fees for each of the transactions, and offering significant scaling efficiencies for more complex situations.

Taproot implements MAST, reducing the number of scripts needed for verification, such that a single MAST transaction can represent multiple scripts. Basically, Taproot is a kind of more advanced MAST which, through the use of aggregate signatures, makes it possible to make a multi-signature condition look the same as the normal one.

It is somewhat like email forwarding, as a visitor on a company's website, you send a message to the mail address on the website e.g, info@test.com, but forwarding makes it possible such that any mail sent to the above mailing address is delivered to one or more different email addresses. So instead of having to put out multiple mailing addresses on a website, one can just put out a generic email address. This is the underlining operation of Taproot signature aggregation.

So when a complex Bitcoin transaction is sent to MAST, the Merkle tree is not necessary for processing transactions. Instead of the full details, MAST only allows the executed conditions of the transaction to be committed to the blockchain, drastically reducing the volume of data needed to be stored on the network.

Tapscript (BIP 342)

Tapscript describes an upgrade that complements both Schnorr and Taproot, One way of understanding Tapscript is by considering the Merkle tree of Taproot, where every leaf is a script that is combined with what we call a leaf version. But the difference is that the scripts aren't revealed at payment time, only at spending time. Different leaves can have different versions, where only the one that is actually used is revealed.

Tapscript is the scripting language used to enable a variety of new transaction types as part of the Taproot upgrade. Tapscript is similar to Bitcoin's Script, the main changes are that it introduces new opcodes, such as OP_CHECKSIGADD, OP_SUCCESS, etc. to allow users to create more complex smart contracts. it improves signature hashing to validate taproot scripts.

Opcodes are basically script commands that are used to send and/or receive transactions successfully. For instance, there is an opcode required to specify the number of signatures required to unlock a multi-signature script. Opcodes have wide usage, they can be used to remove items, perform calculations, check for equality, etc. So these newly included opcodes are extra functionalities that Tapscript adds to the Bitcoin script.

An example would be the difference between Tapscript and Bitcoin script in multi-signature verification. For Bitcoin scripts, to verify multi-signatures, we use the OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY, for example, the script for a 2-of-3 multi-signature transaction would look like this:

2<Public key A><Public Key B><Public Key C>3 CHECKMULTISIG

With Tapscript, these opcodes have been replaced by OP_CHECKSIGADD, and the same multi-signature transaction would look like this:

<A pubkey> OP_CHECKSIG <B pubkey> OP_CSADD <C pubkey> OP_CHECKSIGADD OP_2 OP_EQUAL

The single opcode that replaces the existing two opcodes also ensures batch verification of signatures with Schnorr.

Tapscript enables a more seamless introduction of new features and builds on the batch verifiability of Schnorr signatures. Tapscript also improves signature hashing to validate taproot scripts, allowing users to create more complex smart contracts.
Not only would Taproot integrate new technologies into Bitcoin, but it would enhance the privacy and efficiency of existing features, such as SegWit and Lightning Network, helping Bitcoin scale to a higher transaction throughput and attract a larger user base.

---

Flight attendants, prepare for landing please. Cabin crew, please take your seats for landing.

---

It is good to point out that the introduction of Taproot would not mean an end to ECDSA in the Bitcoin network. Taproot implementation is a soft fork upgrade, meaning that nodes running previous versions interacting with other nodes would still continue to run properly, just that it would be missing out on some new functionalities, which include this Taproot upgrade. Users that want to verify Taproot transactions would have to update their node software. Most wallet service providers will continue to use ECDSA even after Schnorr is activated, but in due time, the broader community will adopt the technology so that most coming transactions are conducted via Taproot.
Taproot is said to be the biggest update to Bitcoin, thanks to its focus on optimizing network scalability, transaction privacy, and smart contract functionality.

Other benefits of Taproot would include lower transaction fees as well as the fact that signatures will no longer be malleable.

Ladies and gentlemen, welcome to your destination, the flight has landed. So do we have to call the cops to bring the handcuffs, or did I do a good job? Leave a comment so I would know.

Just before you go, ever considered a career in bitcoin development, and lightning development? Let me introduce you to Qala

Qala is a program designed to train the next generation of African bitcoin and lightning developers. It goes beyond surface learning and takes you neck deep into the core of bitcoin and lightning development. Qala is a project-based learning program. As a participant, you get to work on diverse projects like open source, personal projects, etc.

Go now and apply to begin your journey in this new exciting world.

until next time/article, Obrigado

Further exploration:

Schnorr Taproot workshop