The Bitcoin Taproot Update

Tl;dr: Bitcoin’s core network just implemented its most anticipated upgrade in 4 years. This upgrade will increase network privacy, efficiency, and ability to support complex transactions.

The Basics: What is the Taproot upgrade?

Taproot is a major upgrade in the Bitcoin network starting from block 709632, which became effective on November 14th, 2021. Taproot is a combination of multiple features, intending to increase the Bitcoin network’s efficiency and security.

The 3 most important parts of Taproot are:

Merklized Abstract Syntax Trees, which allow expressing complex spending use cases efficiently and in a privacy preserving fashion.
Schnorr Signatures with provable security, making it easier to implement Multi-party computation (MPC) signatures.
TapTweak feature, which allows the spender to better-preserve the privacy of their transaction.

I have a Zengo wallet: How will this impact me?

At Zengo, we are closely monitoring Taproot’s adoption and will be gradually adding additional support and functionality as the industry evolves. This is done to ensure that Zengo wallets will be able to send to and receive from Taproot addresses.

At the time of this publication, many exchanges and large wallets, including Zengo, only support receiving funds from Taproot addresses. If a Taproot address sends you coins, there is absolutely no risk of losing the coins. However, we do not support sending coins to Taproot addresses. This simply means that the Zengo app will not allow you to send coins to a Taproot address. We will provide an update as soon as Zengo supports sending to Taproot addresses.

Context: An upgrade 4 years in the making

A new era in Bitcoin has begun, starting from block 709632 (on November 14th, 2021). This is the biggest upgrade to the Bitcoin network and protocol in the past 4 years. While we won’t immediately see significant changes at the user level, these upgraded features will give developers, crypto wallets, and exchanges increased tools to enhance the Bitcoin network’s capabilities over time.

Some of you may have heard about it already under the name “Taproot” and possibly heard some tangential terms such as “Schnorr Signatures” or even “Merkle Branches”. In this post we’re going to introduce you to the Taproot upgrade in the Bitcoin network: why it happened, the problems it solves, and the increased features it brings.

But what is Taproot?

The problem with Taproot is that it isn’t easy to explain because there is no short answer. You see, Taproot isn’t just one thing. In short: Taproot is a set of spending rules introduced to the consensus layer of Bitcoin for handling Taproot addresses.

Okay, now that we’ve said it, let’s try and digest the meaning of this.

Bitcoin (like any other Blockchain) is all about consensus. (Learn more about the basics of the Bitcoin network on our podcast, here.) There are a set of rules, and everyone has to agree on those rules to participate. Transactions and Blocks must abide by these rules, and if you try to publish a new block or transaction which does not comply with those rules, your attempt will be rejected. Some examples of consensus rules are the size of a block or the block reward for miners. Everyone must agree on these so Bitcoin can exist.

One part of the consensus is spending rules: rules that dictate how coins can be spent. The Taproot upgrade introduces a new set of such spending rules. These spending rules are enforced whenever coins are spent.

In order to spend your coins using these new spending rules, you have to use a Taproot address. Therefore, with your existing Bitcoin address (pre-taproot) you will not be able to use all the fancy features we’re going to discuss in this post.

While most exchanges and large wallets, including Zengo, do not currently support Taproot, we are actively monitoring its adoption and plan to introduce Taproot functionality in the future. Zengo already supports receiving Taproot transactions, and plans on introducing full Taproot support soon.

Bitcoin, Privacy and Efficiency

Historically, there have been two main types of addresses in Bitcoin: P2PKH and P2SH:

P2PKH (addresses beginning with a “1”) is an abbreviation for “Pay to Public-Key Hash”. Coins sent to such an address can only be spent by proving that the spender has a specific cryptographic key. This cryptographic key has to be kept secret and must not be lost! If you didn’t know that it’s probably because Zengo already does both of these things for you!
P2SH (addresses starting with a “3”) is an abbreviation for “Pay to Script Hash”. Coins sent to such an address can only be spent if a condition from a set of conditions is met. Those conditions are expressed in a unique language called “script”. For example, the lightning network heavily relies on the script language to enable sophisticated conditions on transactions that enable the transition of funds within the network.
Both P2PKH and P2SH have a “SegWit” variant known as P2WPKH and P2WSH (starting with a “bc1”) which are more efficient but eventually have the same semantics. Spending coins with a P2WPKH address still requires proving the ownership of a certain cryptographic key just like P2PKH and spending a P2WSH requires providing a specific script whose conditions are met just like P2SH.

Before Taproot, when you had a specific Bitcoin address you shared with someone, that person could have known whether it was a P2PKH or a P2SH. This in of itself discloses information about your address that you may have preferred to keep private.

For example, P2SH is heavily used in Bitcoin’s most widespread Layer-2 solution, the lightning network. In fact, each lightning channel is a P2SH multisig address. The tracking of such addresses is part of some chain-analysis procedures that both put the privacy of the lightning network as a whole in question and impedes the privacy of each user in the lightning network.

On top of it, by spending coins from a P2SH address, you must reveal the whole script logic, which is the whole set of conditions in which this address can spend coins.

Let’s take an example. Assume three partners, Alice, Bob and Charlie, own a business accepting payment in Bitcoins. They may prefer receiving those coins with a P2SH address. Thus, to spend coins their business received, they can specify in their script various conditions that any of them should be met, such as:

Any 2-out-of-3 of them can create a transaction.
Any incoming coins that have not been spent for a year can be spent by either one of them.
Incoming coins that were not spent for 3 years can be spent by a designated lawyer.

As you can see, the set of conditions to be met is typically phrased in real-life as many conditions (in our example, 3) where one of them has to be satisfied so that the coins can be spent.

We will not get into how those rules are encoded in script. In order to spend the coins, each and every transaction must include the whole script, even if only the first condition is met. This introduces issues in both the privacy of the users and the efficiency of the blockchain.

The privacy issue stems from the fact that Alice, Bob, and Charlie may prefer not disclosing the whole spending logic behind their address. For example, the identity (address) of the lawyer is public, even though the lawyer isn’t involved whatsoever.
The efficiency issue stems from the fact that the whole script has to be kept on chain for each transaction they make from their address. For very large scripts it can introduce extremely high fees paid by their wallet and leave less space for other transactions in each block.

Taproot Part 1: Merkilized Abstract Syntax Tree

So how can we solve this problem? Typically, in order to spend money from a P2SH address we have a set of conditions that only one of them has to be satisfied. We would like to reveal only the condition that is satisfied in the current spending instead of all conditions. To do this we use a Merkilized Abstract Syntax Tree (MAST). To understand what a MAST is we first have to understand what Merkle Trees are.

A Merkle Tree is a cryptographic tool that is used to commit to a certain set of contents and later reveal a proof for the belonging of some element into this proof.

Let’s see how this can be achieved using an example. Assume we have a set of 4 secret words: Zengo, Penguin, Bitcoin, Wallet.

First, we hash each of these words separately.

For example, the hash of Zengo is A, and the hash of Bitcoin is C.

Now, each two adjacent hashes we hash together into a new node.

So the hash of A and B is X and the hash of C and D is Y.

Finally we hash X and Y together to obtain Z.

Now the only thing we publish only is Z.

Given Z, we can prove that a certain word, Bitcoin, for example, is in the tree by supplying to the verifier the word “Bitcoin” as well as supplementary proof that will allow it to obtain the same root of the merkle tree (i.e. Z).

Our proof will contain D and X. Let’s see how the verifier can verify our claim that the word “Bitcoin” is in the tree. First it will hash the word “Bitcoin” to obtain “C”. Now it can hash C and D to obtain Y. And finally it can hash X with Y to obtain Z. If the Z it obtained is equal to the root of the merkle tree, the verifier accepts our proof and is convinced that Bitcoin is in the tree. However, because it’s hard to reverse hash functions, it should be very hard to convince the verifier that some other word exists in the tree without breaking the hash function itself, which is considered computationally difficult.

Now that we have Merkle Trees in our hands, we can build a Merkle Tree that contains scripts in its leaves instead of simple words like “Zengo” and “Bitcoin”. When we want to spend a certain amount of coins by satisfying one of the scripts in the Merkle Tree we will add to our transaction a proof that the script being satisfied is indeed in the MAST. This way, we only reveal the condition that is satisfied while keeping the other conditions secret, and we don’t need to post the entire script on the blockchain but only the script we needed with a small proof for this script being part of the MAST.

To understand exactly how MASTs are used in post-Taproot Bitcoin, we first have to understand another important feature introduced in Taproot – Schnorr Signatures.

Taproot Part 2: Bitcoin, ECDSA and Schnorr Signatures

To spend their coins, the owners of P2PKH addresses have to prove they are the owners of a specific cryptographic key. This proof is done using ECDSA signatures.

There are multiple issues with ECDSA, however.

It’s very hard to mathematically prove it’s really secure without making some serious assumptions. It is important to mention though, that ECDSA has a long proven history of security and is considered secure in the cryptography community.
Enabling Multi-party-computation based key generation and signing (like we do at Zengo) is very complex.

Is there any alternative to ECDSA you ask? Well yes, there is and it’s known as a Schnorr Signature Scheme.

We will not get into how this signature is computed mathematically but two things important to know about Schnorr are:

Its security is provable from standard cryptographic assumptions.
Implementation of multi-party-computation based key generation and signatures are simpler and more straightforward (and therefore efficient).

But how come the genius inventor of Bitcoin, Satoshi Nakamoto, didn’t think of using Schnorr? Well, it’s merely a guess but probably this is because this scheme was patented up until 2008 so it had very poor publicity when Satoshi first developed Bitcoin and Schnorr signature scheme wasn’t supported in the software stack Satoshi relied on when he wrote the initial version of Bitcoin-core code.

Taproot Part 3: MAST + Schnorr = Taproot

Without getting into too much detail, let’s see how the spending rules of Taproot addresses are working. A taproot address is associated with a public address such that:

While the exact formulation ties to a point on some graph in the x-y plane, you can try and think of it simply as a number. Additionally:

– Is a Schnorr signature public key.
– The root of a MAST associated with address .
– Is a hash function, for simplicity its output is a number.
– Is another point on a graph (or simply a number if you wish) that we multiply the output of by. The value of is known to everybody.

So, if you are given only (again, let’s say that’s a number) that represents some address, we have two different ways to spend coins associated with this address:

Think of as a Schnorr public key, which the corresponding private key is owned by the owner of the address, thus paying using a traditional signature, just that it’s a Schnorr signature instead of the usual ECDSA signature.
Think of as the sum:and provide:
1. A Schnorr public key
2. The root of a MAST
3. Some script
4. A proof the is in the MAST .

And spend with the coins by satisfying the script .

By simply looking at the address we can’t tell how the spender will spend the coins in the future and even if it did spend some coins in the past using a Schnorr signature, it can still spend others in the future using some that it didn’t reveal yet.

How awesome is that?

Notice that we have thought of both and as Schnorr public keys. By owning the private key associated with one can easily compute the private key associated with . We will not get into how exactly this is done but we will say this technique is known as TapTweak and this is a very important ingredient in the construction of Taproot. You can read more about TapTweak in BIP-341 at the end of the post.

Summary

This post gives you a glimpse of what Taproot is, its potential, and why it is so important. It will take some time for the industry to fully grasp and realize its potential, but as of November 14th and Taproot activation, the foundations have now been built.

If you are interested in learning more about Taproot check out BIP-341 (Generally introduces Taproot and TapTweak), BIP-340 (Schnorr Signatures) and BIP-114 (MAST).