Looking for a no BS guide to understanding the Taproot upgrade in Bitcoin?

Tired of reading overly-technical explanations that don’t make sense to you?

You are in the right place.

I am here to explain the Taproot upgrade in layman’s terms so almost anyone can understand it.

Let’s dive in!

Taproot Overview - TL;DR

Taproot is a soft fork upgrade to the Bitcoin Protocol that generally do four things:

1. Introduces a new more efficient type of digital signature
2. Improves privacy of some Bitcoin transactions
3. Lowers fees of some Bitcoin transactions
4. Makes future upgrades to Bitcoin easier by simplifying the language used to develop Bitcoin.

What Upgrades Make Up Taproot?

First, let’s get this out of the way: Taproot is not one upgrade, but three.

These three upgrades come in the form of BIPs, which stand for ‘Bitcoin Improvement Proposals’.

Taproot takes the following three BIPs and rolls them into one update:

• BIP340 (Schnorr)
• BIP341 (Taproot)
• BIP342 (Tapscript)

You probably have no idea what these are, so let’s take them one at a time.

BIP340 (Schnorr)

BIP340 summary on BIPs github page

BIP340 adds a new signature scheme to Bitcoin called “Schnorr signatures”.

What is a ‘signature scheme’ exactly?

Good question!

When a user sends some of his Bitcoin to another user, he must ‘sign’ the transaction, much like you might need to physically sign your name on the title to your car when you sell it to someone.

It is basically your stamp of approval that you are releasing these coins from your custody and ownership to someone else.

Unlike signing a title with your name, in Bitcoin you sign a transaction with a ‘digital signature’. To make this ‘digital signature’, you need something called a ‘private key’ - a long string of numbers and letters that is unique to your wallet. Anyone with your private key can sign away coins in the wallet.

Think of the private key like a totally unique (and completely digital) stamp of approval for sending Bitcoins.

There are many schemes for generating digital signatures, and they all basically serve the same purpose, it’s just that different schemes have different tradeoffs, advantages, and disadvantages.

Historically, Bitcoin has used something called the ‘ECDSA signature scheme’ to sign transactions.

‘ECDSA’ stand for ‘Elliptic Curve Digital Signature Algorithm’.

That’s a mouthful I know, but for now, it’s really not that important to understand the details of that scheme.

Instead, let’s just focus on why Bitcoin uses ECDSA so that we can compare it to Schnorr signatures.

Why Use ECDSA in the First Place?

Legality

The first reason for using ECDSA in Bitcoin was a legal reason. ECDSA was not patented, and therefore anyone was allowed to use it.

History of Reliability

All signature schemes and cryptographic methods work until they don’t. That is to say, you never really know if they are vulnerable or broken until someone finds a vulnerability and exploits it.

When a signature scheme has had no known exploits discovered for a long enough time, your confidence that there aren’t any tends to increase.

Back when Bitcoin was being developed, ECDSA was a tried and tested signature scheme with very few exploits exhibited. Any exploits that had been discovered had largely been fixed.

Certain implementations of ECDSA, such as NIST did have provable back-doors

Despite that, ECDSA had been widely used in a plethora of other applications and on a large scale with few issues or exploits.

This is also true of Schnorr signatures (explained below) but for the reasons stated here, Satoshi could not (yet) use them.

Compatibility

At launch, Bitcoin used the OpenSSL (or ‘Open Secure Sockets Layer’) cryptography library to facilitate encrypted communications between participants on the Bitcoin network.

The OpenSSL Github Repository page

(That’s fancy speak for ‘make sure only the two people talking to each other on the network can understand the communication’).

ECDSA was already implemented as part of OpenSSL when Bitcoin was being developed. So it was very simple to use ECDSA as the standard signature scheme for Bitcoin transactions.

But now you may be asking, “Why use OpenSSL”?

For the same reasons stated above:

• It was open-source and not patented
• It was (and still is) used widely by other applications and seems to work pretty well.

What Do Schnorr Signatures Improve Over ECDSA Signatures?

Now back to the Taproot upgrade and Schnorr signatures.

Why choose Schnorr over ECDSA?

Combining Keys into One

Well the first big advantage comes from the ability to combine keys into a single key so that you can spend from a single signature. This is most useful to people who want to use ‘multisig’ wallets.

These are wallets where more than one person holds a private key to sign transactions from that wallet.

Why would someone want to do this?

There are many reasons, but a common one comes down to escrow.

For example, Bill makes a bet with Ted for 1 Bitcoin that the New York Yankees will win their next game against the Houston Astros.

Ted bets that the Astros will win.

Bill and Ted agree to let Ron settle the bet in case there is a disagreement.

• Bill gets a private key
• Ted gets a private key
• Ron gets a private key

For any funds to be released from that wallet, a transaction must be signed by at least two out of the three private keys.

If both Bill and Ted agree who won, they can settle the bet themselves by using their two keys to send 1 Bitcoin in the multisig wallet to the winner’s wallet.

If they disagree, they can appeal to Ron to make the call. Then Ron and the winner sign a transaction to send 1 Bitcoin from the multisig wallet to the winner’s wallet.

There are many other uses for multisig, but we won’t cover those now. Just know that there are many times when a multisig wallet makes sense.

Now that we know what multisig wallets are and why we use them, let’s get back to Schnorr sigs and their ability to ‘aggregate signatures’.

Using ECDSA and the example of the bet above, there is a lot of data being stored on the blockchain. This data takes up space and it also reveals information about the wallet that compromises privacy for the owners. That’s because each signer’s signature must be stored and verified separately.

Doing the same multisig transaction using Schnorr Signatures allows the signers to combine their signature into one.

• This makes the transaction smaller
• This requires fewer computing resources to verify
• This makes the transaction look the same as standard transactions, so third parties do not know it is multisig.
  

Batching

Bitcoin is built on a network of people who ‘run a node’. This just means you have verified that every previous transaction in the chain adds up. You continue this process as new blocks are added to the chain. This involves verifying all the transactions in that block make sense in relation to all the previous transactions in previous blocks. And with ECDSA signatures, you’ll need to verify each of them one by one.

This is a resource intensive but necessary part of maintaining Bitcoin’s trustless and decentralized attributes.

But what if there were a way to reduce the cost of performing this process of verification?

Enter batch verification.

When senders on the Bitcoin network opt to use Schnorr signs instead of ECDSA sigs, it allows node runners to verify the signatures in batches. Nodes no longer need to verify signatures one at a time, reducing the cost and time to verify.

Why Did Bitcoin Ever Use ECDSA?

For the reasons mentioned above: legality.

When Bitcoin was being developed, Schnorr signatures were patented. Satoshi simply couldn’t use them legally.

Thankfully, the patents ended in 2008, and now anyone can use them.

The Patent on Schnorr Signatures

You may be aware that Bitcoin launched in January of 2009, well after the patents expired.

The famous tweet from Hal Finney announcing that he was running a Bitcoin full node

Why didn’t Satoshi just add them? Why did it take 12 years to add Schnorr sigs to Bitcoin if they are so great?

Satoshi had likely already finished most of the development on Bitcoin before the patents expired. Perhaps he thought it would be better just releasing what he had and count on adding Schnorr sigs later on?

It’s hard to say.

As for why it took so long?

The short answer is: Bitcoin development is slow and conservative. There is also the factor of opportunity cost - there are only so many people developing Bitcoin and there are many competing upgrades.

BIP341 (Taproot)

BIP341 summary on BIPs github page

So what of the Namesake, second BIP to be included in the Taproot upgrade?

What does it do and why do we want it?

Updating Bitcoin Script for Schnorr

Taproot is partially an update to the Bitcoin scripting language (aptly titled ‘Bitcoin Script’). This update allows Bitcoin script to understand Schnorr signatures.

Without this update, the script wouldn’t know how to parse or understand Schnorr Signatures in the first place.

Integrating Merkelized Alternative Script Trees (MAST)

This is a very heady topic and could really be its own post, so in the interest of keeping this article readable in one sitting, I’ll cover the absolute basics here:

Before the Taproot upgrade, users could specify all sorts of spending conditions that had to be met before sending Bitcoin.

• Send at a certain block
• Send only when X of Y signatures sign
• Plus many more

The problem was, when these transactions were created, the sender had to specify all possible spending conditions and these had to be stored, which cost more in fees and also took up more space on the blockchain.

With MAST, the transaction references a ‘Merkle Tree’ of possible spending conditions, without committing to any of them.

MAST thereby allows the sender to hide unused spending conditions. This reduces the total size of the transaction and also preserves some privacy.

Adding Pay-to-Taproot (P2TR) Script Type

A script type is a method of sending Bitcoin from one person to another.

Pay-to-Taproot is a new script type added with Taproot upgrade.

This combines what we learned about MAST and Schnorr sigs above. P2TR allows users to send Bitcoin to either a Schnorr address or sit in a sort of ‘unspent’ state until the spend conditions in the Merkle root of the transaction have been satisfied.

BIP342 (Tapscript)

BIP342 summary on BIPs github page

Now that we understand Schnorr Signatures and MAST, it should make understanding Tapscript easy!

Tapscript was needed in order to allow for the P2TR script type outlined above.

With Tapscript, you can now verify Taproot spends and Schnorr Sigs.

But perhaps most importantly, Tapscript should make upgrades to the P2TR script type easier in the future.

What are the Benefits of Taproot?

Taproot really comes down to two things:

1. Make Bitcoin transactions smaller
2. Make Bitcoin transactions more private

Choosing to utilize P2TR will never hurt you, and there is a sort of herd immunity that occurs the more people that choose to use them over traditional transactions.

That’s because if more people use P2TR for everyday transactions, it makes it harder for chain analyses companies to assume that P2TR transactions are just specialized multisig or ‘encumbered’ transactions with unique spending conditions.

s are just specialized multisig or ‘encumbered’ transactions with unique spending conditions.