Taproot & Schnorr: Scalability and Privacy Upgrades for Bitcoin
By: Galaxy Digital Research
Tags: Cryptocurrency, Blockchain, Bitcoin

Summary: On May 6th, 2019, prominent Bitcoin Core developer Pieter Wiulle sent an email to the bitcoin-dev mailing list titled “Taproot proposal”. The email outlines the goal of three new BIPs (Bitcoin Improvement Proposals) that are vying for addition to the Bitcoin Core code. Two of the proposed BIPs are related to Taproot, a privacy-enhancing and feature-rich upgrade for the Bitcoin scripting language; the last BIP describes the Schnorr signature scheme. Together, Taproot and Schnorr signatures improve both scalability and privacy, and these changes can be implemented in a soft-fork update without forcing broad coordination to upgrade.

Background

Soft-forks vs Hard-forks

It’s important to note that both Taproot and Schnorr can both be implemented as a soft-fork. While it is technically possible to implement a hard-fork in Bitcoin, it is generally regarded as the worst possible upgrade path, for several reasons:

Coordination Backward compatibility Risk of splitting the community

Coordination between major economic, technical, and community players is almost impossible at this point due to the decentralized nature of Bitcoin. Using a flag day or setting a deadline by which everyone needs to upgrade is a serious challenge. Software development teams have design and iteration phases, economic actors worldwide are not always tapped into the same channels, and reaching 100% of the millions of individual users is simply not possible. Backwards compatibility is also a major design decision that cannot be ignored when designing software. Almost all software upgrades that preserve backwards compatibility win out over the long run compared to designs that break and leave older versions unusable. Soft-forks are generally backwards compatible while hard forks are, by definition, not. Finally, there is a major risk of community fragmentation when suggesting a hard-fork, especially given the non-trivial damaging outcomes listed above.

Signature schemes & multi-signature

The elliptic curve analog of the Digital Signature Algorithm (DSA), Elliptic Curve Digital Signature Algorithm (ECDSA) was accepted in 1999 and 2000 as ANSI, IEEE, and NIST standards and provided a number of benefits over the widely accepted RSA algorithm, including smaller key sizes and encrypted messages, faster computation times, and lower demands on memory and bandwidth. Bitcoin uses the secp256k1 elliptic curve with the ECDSA algorithm; the curve’s parameters were specifically chosen in a non-random fashion and enables particularly efficient computation. Notably, Bitcoin public and private keys are usable with ECDSA using the secp256k1 curve and also usable to generate Schnorr signatures.

In many instances, only a single signature is necessary to sign a message or transactions. However, it’s obvious that in certain circumstances having more than one key signing messages or transactions (multi-signature) can be particularly helpful and more secure. Most multi-sig schemes generally require m-of-n signatures that from multiple people, institutions, or programmed scripts. This limits funds from being transferred until the requirement of cooperation between m parties is met.

Basic transactions in Bitcoin (sending Bitcoin to a public key) are known as Pay-to-Public-Key-Hash (P2PKH). Unlike P2PKH, Pay to Script Hash (P2SH) is an advanced type of transaction used in Bitcoin and allows a sender to commit funds to a hash of an arbitrary valid script. P2SH is mainly used for multi-sig and non-native SegWit transactions (P2WPKH-in-P2SH). Originally outlined in BIP 16, P2SH’s purpose is “to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.” [1] Instead of forcing senders to put in long scripts of spending conditions into their scriptPubKey, senders can put a hash of their spending conditions instead known as the redeem script. A P2SH funding transaction contains a hash of a redeem script in the scriptPubKey.

The sender can fund any arbitrary redeem script without others knowing the specific spending conditions for the script — only the recipient(s) know the conditions of further spending. For multi-sig transactions, the sender can send funds without knowing the required public keys of a multi-signature address. The public keys are only revealed when the recipient is spending the funds. When the recipient chooses to spend the funds, they must reveal the whole script as well as the solution to the script; anyone can verify that the supplied script was indeed the original script.

There are drawbacks to P2SH, however. All the possible conditions that could have been met including the conditions that weren’t met must be revealed. This naturally creates potentially privacy issues, as network participants can learn all the possible way that the conditions could have been met, what kind of wallets were used, and more. In addition, it can be particularly cumbersome if there are many possible conditions, in which case the computation and verification becomes data heavy.

Other multi-sig schemes include Shamir’s Secret Sharing (SSS), Threshold ECDSA, Threshold Ed25519, Bohen-Lynn-Shacham (BLS) signatures, and Schnorr signatures; there are many trade-offs between these schemes including but not limited to preimages, trusted setups, interactive rounds, privacy, and computation efficiency.

Schnorr signatures

The Schnorr signature scheme was patented by Claus Schnorr in 1991 and the patent expired in 2008. The main benefit of Schnorr signatures is it makes multi-signature and single-signature transactions indistinguishable on the blockchain. Using Schnorr signatures, multiple signers can produce an aggregated public key and then jointly sign with one signature, rather than publishing each public key and each signature separately on the blockchain. This is a significant scalability and privacy enhancement. Schnorr signatures replacing ECDSA makes Bitcoin’s digital signature infrastructure better in multiple ways, with three key new features:

Non-malleability Linear verification Multi-sig privacy via key aggregation

Non-malleability is a win for Layer 2 networks building on top of the Bitcoin blockchain. One of the major issues with ECDSA is the trivial nature of invalidating a transaction hash before its placed into a block: it is unsafe to accept a chain of unconfirmed transactions since the later transactions depend on the hashes of previous transactions, and so it is recommended to wait until the transaction is confirmed 6 times. With Schnorr, malleability is no longer an issue, streamlining Layer 2 adoption and improving safety.

Schnorr signatures result in significant space savings and savings to verification times. Schnorr signature verification is linear, meaning that the key and signature parts in the signature verification step can be aggregated. This is a new feature known as batch validation, which means validating more than one signature at a time can happen more quickly than before. It is a speed-up gained by validating multiple signatures at the time instead of linearly validating one by one. Naturally, with bigger signature sets, savings increase but eventually taper off.

The ratio of time it takes to verify n signatures individually and to verify a batch of n signatures increases logarithmically with the number of signatures; the time it takes to verify a batch of 100 signatures is 1.75x faster, BIP

Schnorr enables wallet software to aggregate keys together. Schnorr multi-signature outputs look like single signature outputs (more on this below in Taproot). Prior to Schnorr, multi-signature transactions were easy to spot, and could be distinguished from normal transactions on the network. In P2SH, the network is aware of the existence of a multisig transaction, who the signers are, and how many signers are there. With Schnorr, it is impossible for an outside observer to tell the difference, as the signers create an aggregated public key that has a single signature. This helps with scaling, fungibility, and privacy.

There are other minor gains with Schnorr. Schnorr signatures are a fixed 64-byte signature, which is lower than the existing 70–72 byte ECDSA signatures. Schnorr has a formal security proof; there is none for ECDSA. Schnorr has adaptive signatures, which is a feature that helps with atomic swaps, and can also be used for general payment channels.

Taproot & Tapscript

Merkelized Abstract Syntax Tree (MAST)

MAST was originally proposed by Bitcoin protocol developer Dr. Johnson Lau in 2016. [2] MAST proposes a new witness program that uses a Merkle tree to encode mutually exclusive branches in a script, thereby enabling more complex encumbrance conditions, improving privacy by hiding unexecuted conditions/scripts, and allowing inclusion of non-consensus enforced data with very low or no additional cost. MAST allows multiple spending conditions (both multi-signature and time lock conditions) to be structured inside a Merkle tree, and only requires the met conditions to be revealed (as opposed to P2SH’s requirement that all conditions are revealed). If any of the conditions are met, the Merkle root and path can be used to verify that condition resides in the Merkle tree, while keeping the rest of the Merkle tree hidden.

Aside from the privacy benefit, MAST can also create smaller transactions sizes. Non-MAST transaction sizes increases in cost linearly while MAST transaction sizes increases only logarithmically, offering significant scaling efficiencies for more complex encumbrance situations. This is particularly relevant given the byte size hard limits in Bitcoin; bare scripts and SegWit have a 10,000-byte limit, and P2SH transactions have a 520-byte limit.

Number of sub-scripts and encumbrance data size with and without MAST, source

Taproot

The Taproot upgrade, a particular implementation of the MAST protocol, makes outputs and cooperative spends indistinguishable from each other. [3, 4] Taproot, like MAST, uses Merkle branches to hide the unexecuted branches in scripts. This scripting update, known as Tapscript, means partially-executed scripts have the rest of their execution code hidden until it’s used while still preserving the integrity of that code when it is later validated and verified by peers. Taproot and Tapscript are designed from the get-go to be versionable and upgradable. Their addition to the codebase is not a major change, in their entirety, the consensus changes to implement Taproot and Tapscript are only around 500 lines of code.

Using a specialized bitcoin script is easily identifiable, and looks different than a simple spend from an address to an outside observer. With Taproot, outputs all look the same. Taproot’s real innovation lies in its flexibility for privacy-preserving cooperative spends: there are situations where the evidence of a Merkle tree’s existence does not need to be published and only a single public key and single signature need to be published. Bitcoin users can use it as programmable money without identifying that they’re using it for that purpose, improving both privacy and fungibility.

All participants of a script can agree on the outcome, regardless of the existing conditions, and simply sign off on a spending transaction together. This “cooperative close” utilizes a Schnorr “threshold signature” such that the transaction looks like a regular transaction — the public keys of the participants are aggregated together into a threshold public key, and is multiplied by the hash of the script (all the “non-cooperative” closes). To the chain, this cooperative transaction appears as a regular transaction with a traditional public key and signature.

Only under non-cooperative spends does the existence of the Merkle tree have to be revealed. In non-cooperative spends, the original threshold public key can be tweaked with the conditional script that is met to create a tweaked threshold public key; this proves that the funds of the script can be spent if the specific conditions of the script are being met. Alternatively, the threshold public key can be tweaked with a Merkle root of the MAST structure of all the different conditions for spending the funds of a script. This way only the spend condition that is met must be revealed and the remaining conditions can remain hidden, thereby improving privacy and optimizing the use of network resources.

Future upgrade path

Schnorr signatures and Taproot with Tapscript improve scalability and privacy by hiding scripts and obscuring keys, and limit the ability for third parties to ascertain the types of transactions occurring. These improvements can drastically improve the adoption, security, and safety of multi-signature transactions. In the future, Bitcoin developers and its community plan on integrating these enhancements within the core code. Various privacy-focused upgrades are slated for addition to the Bitcoin Core code and will make transactions safer, more private, and bitcoins more fungible.