How Will Taproot Benefit Bitcoin?
In the second installment of our series on BIPs 340–342, we’ll explain how Schnorr paves the way for Taproot (BIP 341) and explain the benefits for Bitcoin.
Read part 1 ‘How will Schnorr Signatures Benefit Bitcoin?’ here.
What is Taproot (BIP 341)?
BIP 341 is the second part of the Schnorr/Taproot/Tapscript proposal and extends on Schnorr’s functionality to enable greater scaling, efficiency and spending policy privacy.
As explained in our first article on the three-part proposal, Schnorr enables bitcoin multi-signature transactions to appear as if they were standard (i.e., Pay-to-Public-Key-Hash) transactions on the blockchain.
Taproot (BIP 341) when combined with Schnorr takes this even further, enlarging the group of transaction types that appear to be the same set to include:
- Use of P2PKH and P2WPKH, i.e., single spends,
- n-of-n spends with MuSig or equivalent (similar to current use of P2SH and P2WSH 2-of-2 multi-sig),
- k-of-n (for low values of n) using the most common k signers, and
- Lightning Channel closes, atomic swaps and other contract protocols that can sometimes result in all parties agreeing on an outcome.
These four cases categories represent a majority of Bitcoin’s transactions to date. No matter how complex a contract is, Taproot enables the cooperative outcome to appear the same as single key spends on the blockchain. The remaining scripts that outline other contract outcomes are not added to the blockchain, freeing up space for more complicated transactions in a given block.
Before explaining how Taproot works, it is useful to know that it is an implementation of the MAST protocol — which is detailed below.
What is MAST?
MAST (short for Merkelised Abstract Syntax Trees) was originally proposed in 2016 by Bitcoin developer Dr. Johnson Lau.
MAST proposes the use of a new witness program and makes use of a Merkle tree to encode mutually exclusive branches in a script. A Merkle tree is a data structure and the term tree is used to describe the branching structure. It usually displays the root at the top while the leaves are at the bottom of a diagram, as illustrated below.
Figure 1: Merkelised Abstract Syntax Tree (MAST)
A Merkle tree is created by individually hashing each script to get a short unique identifier. Each of those identifiers are then paired with another identifier and hashed again, producing another short unique identifier for that pair.
It is an interative process and continues until only one identifier remains, called the Merkle root — Address = Hash (1, 2) in the diagram above — which uniquely identifies the whole set in just a few bytes of data. We can think of the Merkle root as a lockbox for the coins.
In contrast to Pay-to-Script-Hash (P2SH), MAST permits multiple spending conditions to be structured in a Merkle tree. Only the conditions that are met are revealed, where the Merkle root and path is used to verify that the condition lies in the Merkle tree, while keeping the rest of the tree hidden.
For example, if we have some complex script that says a party cannot use spend their coins until a month has passed (i.e., a timelock) or they could be spent with a 3-of-5 multi-signature transaction, then as it stands in bitcoin today, both conditions will be revealed once the coins are spent.
The unique benefit of MAST is that if any of the data in the Merkle tree is revealed, the Merkle root and some additional data (called the Merkle path) can be used to verify that that specific data was included in the Merkle tree. The rest of the tree (and therefore the other conditions) remains hashed and hidden. This means that only the condition that is met needs to be revealed if all participants agree.
Users of complex encumbrances can create smaller transactions and the efficiency gains are greater with more complex contracts with a larger number of sub-scripts. MAST makes it possible to have many more conditional branches as compared to using any other current mechanism. This opens up the support for more advanced smart contracts with no additional costs bourne by Bitcoin nodes.
In Figure 1 above, Alice can even add a longer chain of beneficiaries to the MAST structure without affecting the number of bytes she uses. There’s no increase in fees paid to miners, as she can still spend her bitcoins using just 32 bytes. On the network level, blocks will be able to hold a larger number of complex transactions.
The downside is that, by default, everyone has to use a MAST structure to maintain the privacy set. The top branch of the Merkle tree is always visible, meaning that observers can figure out that other spending conditions exist. Also, there is a burden for most transactions which do not have a requirement for a contingency script, increasing costs.
MAST has never been implemented into Bitcoin so far because the changes needed are far-reaching and complicated. This is where the Schnorr/Taproot/Tapscript proposal comes in, as a middle ground between simplicity and extra functionality.
How Does Taproot Improve on MAST?
Taproot is a proposal for Bitcoin developed by originally by Greg Maxwell, Peter Wuille and Andrew Poelstra. It was later taken up by ten major contributors on the IRC and bitcoin-dev mailing list. While Schnorr adds a new signature type, Taproot builds on this further by introducing a new transaction output version and a new way to define spending conditions.
Taproot has its own version of a Merkle tree, called a script tree. Participants can choose to spend with: 1) a pubkey as a regular signature or 2) spend with a script.
For the first instance is the default spending path, where single or multi-party public keys are indistinguishable. For alternative spending paths, hidden scripts are not revealed unless we spend. Different scripts can be organised into a Merkle tree and outputs can also be spent by revealing one of the clauses.
If we spend the transaction with the primary spending script, we simply provide a Merkle proof, which consists of the primary spending script and the hash of the alternative spending script, which is enough to prove that the primary spending script was in the script tree.
Taproot uses a MAST structure to hide the conditions behind the Merkle root. The Merkle root itself is then hidden with a key commitment and enables direct spends with the key. Only a single key goes onto the blockchain and no one sees that additional conditions exist.
In combination with Schnorr, the MAST structure is hidden with Taproot outputs. At the top of the Merkle tree, there is an option for a single public key and signature to be published. In effect, this makes P2PKH and P2SH transactions look identical.
To illustrate an example, consider closing a Lightning channel.
Lightning channels are a variant of 2-of-2 multi-signature. Instead of closing with a cumbersome script, Schnorr enables us to join signatures and present these together as a Taproot pubkey/signature. When both parties agree, it looks like someone spent that input with regular signature to two addresses. An observer would not be able to tell it is a Lightning channel.
Figure 2: TapBranch
To hide the MAST structure, the TapBranch Hash in Figure 2 above is hashed with the aggregate public key (remember, thanks to Schnorr, Alice and Bob can add their public keys together to create the taproot internal key).
The resulting hash is used as a private key from which another public key is derived, the tweaked pubkey. Tweaking the keys, also known as key pair concealment, involves embedding the scripts 1 and 2.
The tweaked pubkey is then added to the taproot internal key to create the taproot output key. The process is simplified in Figure 3 below.
Figure 3: Tweaking public keys with Taproot
The Taproot output key can be used to pay any of the three conditions. In the example above, if Alice and Bob both agree on a Lightning payment, they can collaboratively join Schnorr signatures together, create a master public key, add the signatures together and produce a master signature.
Both parties each partially sign with their individual signatures and the closing of a Lightning channel looks like a straightforward payment to pubkey.
In the uncooperative case, only the script that is used is revealed. Verifiers will be able to tell that a threshold public key was tweaked with the Merkle root of the MAST structure. However, all other options/scripts remain hidden.
From Figure 3, we can also see that the script tree provides a new recovery option for accessing bitcoins. Taproot enables a new recovery option for lost coins (for users with upgraded wallets). In the case of a single key, if you lose it, it’s gone forever. In contrast, if you lose your private key and your funds are in the form of a Taproot output, there should be another path through which you can re-claim your coins (for instance, you’ll recover 3-of-5 backups keys that are held by your family).
Summary
In summary, Taproot (BIP 341) improves privacy, efficiency and the flexibility of Bitcoin’s scripting capabilities, enabling developers to write complex scripts while minimising the on-chain impact.
In terms of scaling, complicated transactions realise significant savings on transaction fees, as data-intensive scripts no longer have to pay fees higher than a standard Pay-to-Public-Key-Hash transaction. The efficiency gains are greater the more complex transactions there are on the network.
Since we can execute complicated transactions using just one signature, the number of bytes used for aggregated keys and signatures is exactly the same no matter how many signers are involved. In contrast, with Pay-to-Witness-Script-Hash (P2WSH) multi-signature, each additional pubkey adds 8.5 vbytes and each additional signature adds about 18.25 vbytes.
In terms of privacy, BIP 341 aims to minimise the information that is revealed on chain about the conditions to spend for a transaction output. With Taproot most applications can use the key-based spending path, which is private and can be generalised to m-of-n multi-signature policies.
While Schnorr makes multi-signature transactions look like ‘regular’ Pay-to-Public-Key-Hash transactions, the addition of Taproot extends the types of transactions that will look similar (making Pay-to-Public-Key-Hash and Pay-to-Script-Hash indistinguishable).
As with SegWit and Schnorr, wallets and services will have to upgrade to make Taproot functional. As more users take advantage of Taproot’s functionality, the positive effects on efficiency and privacy are amplified.
Taproot also opens the door for other privacy gains. For instance, it would enable atomic swaps with adaptor signatures, which would also be indistinguishable from other types of transactions. These swaps could end up being used as a mixing mechanism (similar to CoinJoin), but the benefits rely on wide adoption of Taproot outputs by wallets and service providers.
Another interesting thing enabled by Taproot, but not included in BIPs 340–342, is cross-input aggregation. While key aggregation is useful for multi-signatures transactions that spend a single input, most transactions combine multiple inputs together. With cross-input aggregation, a single signature is required to spend all inputs in a transaction simultaneously and would incentivise the usage and adoption of CoinJoin. Schnorr-based CoinJoin transactions will also look like regular, single-signer transactions to outsiders.
Cross-input aggregation is not included in BIP 341 is because of the extensive changes and checks that are required. Developers want to avoid any adverse affects on Bitcoin’s security from new features while still providing a solid base for further upgrades and functionality (such as cross-input aggregation).
In the final part of the series on Schnorr/Taproot/Tapscript, we’ll explain what Tapscript (BIP 342) is and the possible activation methods for BIPs 340–342.
Have any questions about BIP 341/Taproot? Let us know in the comments below.
About Interdax:
Interdax — the first competitive crypto trading platform. Trade crypto derivatives with up to 100x leverage while competing to win big prizes in matches and tournaments. Built by former NYSE / Nasdaq engineers.
