What is Taproot?

What does Taproot enable?

If Schnorr signatures allow multisignature transactions to look like standard Pay-to-Public-Key-Hash transactions, Taproot combined with Schnorr extends this, enlarging the set of transaction types that can be made to appear standard:

• use of P2PKH and P2WPKH, i.e., single-key spends;
• n-of-n spends with MuSig or equivalents (akin to today’s use of P2SH and P2WSH 2-of-2 multisignatures);
• k-of-n (for minimal values of n) using the most common k signers;
• Lightning Network channel closures, atomic swaps and other protocols that may sometimes result in all parties agreeing on the outcome.

These four categories of use cases represent most Bitcoin transactions today. Regardless of a contract’s complexity, Taproot lets the joint outcome recorded on-chain look like a single-key spend.

The other scripts, which encode alternative outcomes, are not added to the blockchain, freeing up space in a block for more complex transactions.

How does Taproot work?

Understanding Taproot requires first understanding MAST.

The MAST technology (a Merkle-tree-based abstract syntax tree) was proposed in 2016 by the developer Johnson Lau.

MAST introduces a new witness program and, using a Merkle tree, decodes mutually exclusive branches in a script.

A Merkle tree is a data structure; the term “tree” describes the shape of its branches. It is usually depicted as in the graphic below: the root at the top, the leaves at the bottom.

With MAST one can create complex contracts with many different clauses. Only the executed script is revealed, which saves block space and enables more sophisticated scripts/contracts.

A Merkle tree is created by hashing each script individually to obtain a short unique identifier. Each identifier is then combined with another identifier and hashed again, creating a new short unique identifier for that pair.

This process repeats until only one identifier remains, called the Merkle root (Address = Hash (1,2) in the graphic above), which uniquely identifies the entire data set in a few bytes. The Merkle root can be thought of as a “vault” for coins.

Unlike Pay-to-Script-Hash (P2SH), MAST lets many spending conditions be structured in a Merkle tree. Only the fulfilled conditions are revealed: using the root and the Merkle path proves that a condition is included in the Merkle tree. The rest of the tree remains hidden.

For example, if we have a complex script stating that a party cannot spend its coins until a month has passed (a timelock), or that the coins can be spent via a 3-of-5 multisignature, then both conditions are revealed once the coins are spent (as works today in Bitcoin).

MAST offers the following: if any data in the Merkle tree are revealed, the Merkle root and a set of auxiliary data (the Merkle path) can be used to prove that specific data were included in the Merkle tree. The rest of the tree (and thus other conditions) remain hashed and hidden. This means that, provided all participants agree, only the executed condition needs to be disclosed.

Users of complex contracts can create smaller transactions, and the efficiency gains are greater for more complex contracts with more sub-scripts. Unlike other mechanisms, MAST allows many additional branches, enabling more advanced smart contracts without imposing extra costs that would burden Bitcoin nodes.

In the illustration above Alice can even add a longer chain of beneficiaries to the MAST structure without changing the number of bytes used. Fees do not increase because she still spends her bitcoins using just 32 bytes. At the network level, blocks will be able to process more complex transactions.

The flaw is that, by default, to maintain adequate privacy everyone would have to use the MAST structure. The top branch of the Merkle tree is always visible, and observers can infer that other spending conditions exist. It also increases the burden on most transactions that do not need an additional script, making them costlier.

MAST has not yet been implemented in Bitcoin because the required changes are too complex and may have hard-to-foresee consequences. The Schnorr/Taproot/Tapscript package could be a golden mean between simplicity and additional functionality.

How does Taproot improve MAST?

Taproot offers its own version of a Merkle tree, called a script tree. Participants can choose to spend using:

• a public key, as an ordinary signature;
• a script spend.

In the first case this is the default spending path, where single- and multi-party public keys are indistinguishable.

In the second case hidden scripts are not revealed until a spend occurs. Different scripts can be organised in a Merkle tree, and outputs can also be spent by revealing one of the clauses.

If we spend a transaction using the primary spending script, we simply provide a Merkle proof consisting of the primary spending script and the hash of the alternative spending script—enough to prove that the primary script is contained in the script tree.

Taproot uses a MAST-like structure to hide the conditions behind the Merkle root. The Merkle root itself is hidden in this scenario and allows direct key-based spends. Only a single key is sent to the blockchain—nobody sees that additional conditions exist.

In combination with Schnorr signatures the MAST structure is concealed by Taproot outputs. At the top of the Merkle tree there is an option to publish a single public key and signature. As a result, P2PKH and P2SH transactions look identical.

Closing a Lightning channel illustrates this.

Lightning channels are variants of a 2-of-2 multisignature. Instead of closing a transaction with a bulky script, Schnorr allows the signatures to be aggregated and presented as a Taproot public key/signature. When both sides agree, the result looks as if someone spent the output with a regular signature, paying two addresses. An observer cannot tell it was a Lightning channel.