Bitcoin 201: Schnorr and Taproot

Two new Bitcoin proposals that will improve the signing process are on the horizon. In this post, we’ll explain these two technologies in the friendliest way possible.

This is a pretty technical topic, so we've deemed it worthy of being a Bitcoin 201 instead of the typical 101. Let’s start with a little background info.

To spend bitcoin you must prove ownership of a particular UTXO’s private key. To prove ownership, a Bitcoin wallet uses both your transaction data and private key in order to create a cryptographic signature. That signature is used to prove that your transaction is legit without exposing the associated private key. In other words, you can spend your bitcoin without worrying that someone will see your private key and swipe your funds.

There’s still room for improvement in signing technology, especially in areas such as privacy and scalability. That's where Schnorr, MAST and Taproot come in.

Scripts and Their Shortcomings

The above section explained how a single signature determines how bitcoin can be spent. However, transactions may also use other conditions, such as multi-signature transactions (a specific number of signatures from of a set of private keys are required to spend funds) or timelocks (funds cannot be spent until a specified time elapses). These conditions are defined by redeem scripts, which are essentially code that adds additional rules to a transaction, and can add complexity to the verification process.

For example, a script might have one condition requiring that Alice waits a week until her bitcoin can be spent. A more complex script might have two conditions, making it so that Alice must wait a week or her husband, Bob, must also provide a signature before any coins can be spent.

At present, when bitcoin is sent, those coins’ script is committed to the blockchain in the form of a long string of random numbers, known as a hash. One single hash acts like a fingerprint for all the conditions in the script. It isn’t until the owner of those coins spends them that the entire script is revealed. This allows for verification of ownership by third parties.

There are two primary issues with scripts as they stand today.

1. The more complex the script, the larger the data size of the transaction, which results in increased transaction fees.
2. When a script’s conditions are revealed, even those that weren’t fulfilled are uncovered. In the example above, if Alice waits a week to send funds without Bob’s signature, verifiers can see that waiting for Bob’s signature was also an option—a dead giveaway that Alice is using a multisig wallet. This is an inherent privacy limitation and is not an efficient use of blockchain space.

MAST

If signature technology could “level up,” MAST (Merkelized Abstract Syntax Trees) structures would be level two. MAST makes it so that only the fulfilled script condition(s) are revealed upon spending the coins. It does this by nesting individual hashes within one single hash known as the Merkle root.

For example, let’s use the multi-condition scenario posed above—that Alice must wait a week to sign a transaction or Bob must also provide a signature. With MAST, if Alice waits a week to sign but doesn’t co-sign with Bob, the verification process will only reveal the fulfilled timelock condition. No one will know that a multi-signature condition was available.

MAST’s ability to nest hashes makes transactions more private and easier for the blockchain to handle. Schnorr signatures improve upon MAST by providing even greater privacy and efficiency for complex scripts.

Schnorr

Schnorr signatures have two main benefits: signature aggregation and key pair concealment.

Signature Aggregation

Schnorr allows multiple signatures and public keys to be combined into one single signature or public key, making them indistinguishable from single-signature transactions. These are known as threshold signatures and threshold public keys, and they have massive implications for the privacy of multisig transactions.

If Alice and Bob co-sign on a transaction, verifiers will have no way of knowing that there was more than one signature. That means you never have to worry about what the scripts might reveal—it’s already taken care of.

Key Pair Concealment

Schnorr would also allow public and private keys to be cosmetically altered to disguise themselves. Nothing about the transaction, scripts, or signatures changes—only how the key is visually represented changes. Anyone who doesn’t know the key pair has been cosmetically altered is none the wiser. The best example I’ve seen comes from Aaron van Wirdum:

A private key and a corresponding public key could be tweaked by multiplying both by two.

The [private key x 2] and the [public key x 2] would still correspond, and the [private key x 2] could still sign messages that could be verified with the [public key x 2].

Both of these features, as well as improvements from MAST, serve as the backbone of Taproot.

Taproot

If a scripting condition requires that two people wait a week to spend funds, wouldn’t it make more sense to allow those parties to transact sooner, provided they mutually agree? With Taproot, transactions will always include a script condition where participants can do just that. This is known as a cooperative close, and is only the beginning of Taproot’s benefits.

Taproot uses threshold signatures to make cooperative closes look like a single signature transaction. However, there are often other conditions present for spending those funds. Rather than revealing those conditions, Taproot will combine them into a separate script. That script is then hashed and used to conceal the threshold signature using the same technology behind Schnorr.

Instead of [public key x 2] as with the earlier example, it looks more like: [threshold public key x script], where the hashed script of unused conditions modifies the threshold public key. The same can be said for the threshold signature—[threshold signature x script]—which allows participants to spend the funds.

Verifiers will still see this as a normal transaction—a plain old key with a plain old signature. The catch, however, is that if a cooperative close isn’t reached, verifiers will see that the public key has been tweaked. In order to prevent denial of this transaction, the original threshold public key and script are revealed to prove their connection to the transaction. That means that all of those unfulfilled spending conditions are left out in the open.

Luckily, Taproot can still solve for this. Instead of modifying the threshold public key with a script, Taproot permits the Merkle root of a MAST structure to be used ([threshold public key x Merkle root]). Thus, much like MAST, in order to spend funds, only the spending condition met must be revealed, and voila: we’ve solved for uncooperative closes.

Taproot and Schnorr aren’t yet activated on Bitcoin. Both features are currently being lumped into one proposal backed by multiple Bitcoin Core contributors, with Schnorr in development as a soft fork protocol upgrade.

The timetable may not be clear, but the benefits are so immense that it’s likely a matter of when, rather than if.