Taproot is wider than you think

Author: A Jian

The title of the article comes from Bitcoiner Xiong Yue.

Bitcoin's Taproot soft fork upgrade will be activated at Bitcoin block height 709632 (expected November 15, 2021). This upgrade contains many important and wonderful contents, however, it lacks enough attention in the Chinese world. This article will briefly introduce the upgrade content of Taproot from a technical point of view, and reflect the development direction of Bitcoin.

The common narrative is that Taproot improves Bitcoin's privacy, smart contract functionality, homogeneity, and so on. However, in order to understand the content and imagination of Taproot's upgrade, we need to understand some bitcoins first.

Smart Contracts on Bitcoin

What many people don't understand is that Bitcoin also supports programming smart ^contracts2 , but the type of smart contracts is different from other blockchains (such as Ethereum). A detailed explanation of this distinction would require a separate article, and it is not important here. Here are just a few common ^modules3 of Bitcoin smart contract programming, so that everyone can understand its application scenarios:

• Multi-signature contracts. Bitcoin supports multi-signature authorization to use funds: Among the N recorded public keys, there must be private keys corresponding to M public keys (for the same operation) signing, and the funds can be used. Bitcoin supports multi-signature contracts with up to 15 public keys.
• time lock. Users can use two types of time locks to specify the available period of a fund: (1) CLTV, an absolute time lock, defined by a specific time or a specific block height, and can only be used after this time; (2) ) CSV, relative to the time lock, for example, the funds can only be used after 1000 blocks on the chain of the transaction that generated the funds.
• Multi-conditional programming. That is, use the "IF ... ELSE ..." statement in the script to set multiple unlocking conditions for the same fund, and the fund can be used if any condition is met. For example: "The private key corresponding to the public key of A can be unlocked, or, after the block height XXXX, the private key corresponding to the public key of B can be unlocked, or, after YYYY blocks on the chain of the transaction, A, The private keys corresponding to any two of the three public keys B and C can be unlocked”

As readers can imagine, these modules look very simple, but there are many possibilities to combine them: multi-signature contracts define the permissions of different subjects, and can adapt to extremely rich application scenarios, from company operations to family treasury; time The lock specifies the permissions of different subjects at different times. Multiple conditions significantly magnify the combined effect of these permission controls.

You can even make a contract that supports social recovery and has an inheritance distribution effect with only a few conditions: "I (A public key) can control this fund; if no one uses it for three months, I (B public key) ) and four friends, three out of five can control this fund together; if no one uses it for a year, my wife can control this fund.”

However, for these contracts to actually be useful, two factors cannot be ignored: efficiency and privacy.

Efficiency means that the transaction fee of Bitcoin is calculated according to the volume of the transaction, and scripts with more conditions will take up more space (in bytes), and the transaction fee will be higher.

The consideration of privacy is that the exposure of the script will make others know that some public keys are associated with each other, making it easier to analyze the real identity of the owner of the public key.

Currently, Bitcoin's contract is embodied as a P2SH "address" (actually a hash value). Its characteristic is that when the contract is generated, the script can not be disclosed, and the hash value of the script is paid directly if necessary; however, when these funds are spent, the script corresponding to the hash value will be fully disclosed and put in the transaction (otherwise there is no way to verify that the hash of this script is exactly this hash). Taking a multi-signature contract as an example, others can directly pay the hash value of the multi-signature contract script, but when the participants of the multi-signature contract want to use these funds, they must disclose the entire ^script3 .

In addition, before the SegWit upgrade, there was a clear distinction between single-signature personal wallets and contract wallets. The former is a P2PKH address, and the latter is a P2SH address. It can be seen from the address alone, which is another factor that is unfavorable to privacy. After the SegWit upgrade, personal wallets that support Segregated Witness can also take the form of P2SH, but the original Segregated Witness address (P2WPKH) and contract address (P2WSH) are still distinct ⁴ .

With that in mind, let's see how the three parts of the Taproot upgrade (MAST, Schnorr signatures, Taproot) can do better.

Merkle Abstract Syntax Tree (MAST)

The meaning of Merklized Abstract Syntax Trees (MAST) ⁵ is to support the verification of Merkle evidence in Bitcoin script verification.

A Merkle tree is a cryptographic method of hashing multiple data elements into a single hash value. Its structure and the characteristics of the hash function determine that some evidence (hash value) can be provided to prove that a certain data element participated in generating the hash value. As shown in the figure below: we continuously hash the (adjacent) data elements in pairs, and finally generate a Merkle root.

Similarly, as shown in the figure below, when I want to prove that the red data "Banana" participated in generating the purple hash value (Merkel root), I only need to provide the red data and three green hash values. Exposure actually co-generates the remaining 7 elements of the Merkle root. This is what Merkle trees and Merkle proofs do.

Individual Merkle proofs for Banana, Peach and Kumquat

Smart readers must have thought that with this function, the writer of the contract can divide multiple conditions into different data elements and hash out a Merkle root value; when a certain condition is needed to unlock Bitcoin When , it is only necessary to prove that this condition is on this Merkle tree, and there is no need to disclose all other conditions.

Yep, that's exactly what MAST does. As shown in the figure below, there are two unlocking conditions for this fund, and the writer separated them and abstracted them into a hash value with a Merkle tree. When unlocking and using any one of the conditions, no Make another public.

MAST has taken a big step on the basis of P2SH, and its improvement effect is first reflected in privacy: originally in P2SH, the contract must disclose all script content when it is used, regardless of whether the content is used or not. All must be disclosed; now, with MAST, users only need to disclose the unlocking conditions that need to be used, and there is no need to disclose all the content; at the same time, others do not know how many conditions you still have.

Secondly, it also improves efficiency: users only need to provide some scripts that need to be used, and their Merkle evidence. When the entire script is relatively large, the effect of this volume saving will be very obvious.

As a result, future bitcoin users can write contracts with a lot of conditions to obtain better control effects and only need to pay less handling fees; even, they can intentionally include some garbage conditions to enrich the Merkle tree and obtain privacy improvements Effect.

This is also the origin of the subtitle of this article "Hash is the bank": Bitcoin's script actually revolves around the control of funds. The key to achieving this control is multiple conditions. With MAST, even if there are many conditions The asset management script of , can also be compressed into a hash value, and only part of it needs to be exposed when used. The reduction in cost can open up a lot of possibilities, waiting for wallet developers to find out.

Schnorr signature

After the Taproot upgrade, Bitcoin will not only support elliptic curve-based cryptographic signatures, but also support the Schnorr digital signature ^scheme6 .

The construction method of Schnorr signature is not mentioned here, we only introduce its important properties: signature/key aggregation - signatures of multiple private keys can be aggregated into one signature, which looks as if it was signed out by a single private key. When signing, it is still signed by each private key holder; when verifying the signature, it seems that these signatures are a private key corresponding to a known public key (of course, the public key aggregated by the public keys of these participants). key signed out.

In other words, with the Schnorr signature, others cannot tell whether a signature is signed out by a single person or by multiple people; the unlocking condition of a multi-signature can be replaced by an aggregated public key. All nn multi-signature contracts can enjoy the privacy protection provided by Schnorr signatures. Its most obvious application is the Lightning Network channel, because the Lightning Network channel is a 2-2 multi-signature contract; after that, others will not be able to distinguish payment channels and individual users based on the number of signatures.

As for mn's multi-signature contract, don't worry, don't forget that we have MAST: we can turn all possible unlocking situations into a branch, and when using a branch, the signature provided only needs to be an aggregate signature. For example, suppose we want to make a 2-3 multi-signature contract, and choose two of the public keys A, B, and C. The effect of this multi-signature contract is equivalent to "either (A, B) unlocks, or (B, C ) unlock, or (A, C) unlock", which can be understood as a multi-condition script, each condition is a 2-2 multi-signature, so the corresponding aggregated public key can also be used to define the unlock condition (and does not need to be defined in terms of multi-signature). Therefore, when we need to unlock funds in a certain combination, we only need to use MAST to expose a branch and provide a signature, and others still don't know whether it is one person, two people, or multiple people.

It's not over yet.

Taproot

According to the path we understand, the last part of the Taproot upgrade is Taproot, which is the origin of its name. In proposing this concept, Gregory Maxwell ^wrote7 :

A question that often comes up when discussing Merkleized scripts is whether we can implement a smart contract that is indistinguishable from the most common and boring payments. Otherwise, an anonymized set of outputs using these trendy techniques, which is just another niche set, doesn't make much sense in practice.

Here, Maxwell grasped the point of the problem keenly: the privacy protection of Bitcoin comes from "big hidden in the market". It is the most difficult to grasp. However, when new functions are introduced, it is inevitable to propose a new type of "address". If there are few users using this function, the possibility of each user's real identity will be greatly increased, and this may lead to these problems. The new functionality will not be used at all, thus losing its meaning.

Moreover, although MAST plays an important role in the privacy of the contract, if it is still the same as in the past, the personal wallet is a personal wallet, and the contract wallet is a contract wallet. If it is clear at a glance, it must be said that such privacy is still flawed. .

People urgently need a way to end this personal wallet/contract wallet distinction and add the finishing touch to Bitcoin's privacy. For this reason, the minimum thing to realize is that the cost of this kind of wallet with contracts is no different from ordinary personal wallets (economical) in the daily use of users.

Taproot is such a method. It takes advantage of the characteristics of key aggregation and proposes a script mode with two usage paths: one is nn multi-signature contracts; the other is user-defined contract scripts.

Following the example in Maxwell's original text: Suppose two users have public keys A and B, and the two aggregate public keys A + B = C, and then generate the final public key P = C + H(C||S)*G, where S is a custom script. The final public key P is used to define the unlocking conditions of funds. Assuming that both users are online, they can easily use the funds together, as long as one of them adds H(C||S) to his private key when signing; if only one of them is online, for example, S defines The conditions under which B can spend funds, Taproot's rules allow users of public key B to spend funds by revealing the aggregated public key P and H(C||S) and providing conditions under which S can be satisfied.

The 2-2 multi-signature contract is used here, but users can imagine that as long as the key aggregation technology is available, 1-1, that is, single signature, can also use this method of writing scripts. The important points are: (1) Although this is a fund with a custom contract, when the contract is not used and only nn multi-signature is used, its handling fee cost is no different from that of a fund unlocked by a single signature! (2) When using nn multi-signature, others have no idea that this fund can be unlocked and used in other ways!

In this way, both individual users and contract users can be unified under one script mode (P2TR "address"), and individual users can safely add contracts to their own funds without worrying about paying higher handling fees on a daily basis; contract users Individual users enjoy a greater anonymity set because they use the same "address", and even use the contract without exposing themselves in most cases. Everyone is happy.

All in all, after Taproot, others will not be able to tell whether a P2TR address is an individual user or a contract user from the address form; due to the effect of the Schnorr signature, when the funds in this address are unlocked with a single signature, others will not be able to tell whether it is an individual user or a contract user. Whether it is used by one person or n people together, it is impossible to know whether there is a custom script at this address; due to the effect of MAST, when users use custom scripts to spend funds, they only need to expose the parts that need to be used Script; although others know that this address has a custom script, it is still unknown what conditions the entire script includes.

So, while some have questioned that Taproot might in turn harm Bitcoin's ^privacy7 , I'm not at all so concerned. Because Taproot "address" is undoubtedly the best in the history of Bitcoin in terms of convenience, privacy, and economy, it is fully hopeful that it can unify the "address" type of Bitcoin and form the largest anonymity in Bitcoin history. set.

epilogue

For those who know some cryptography technology, learning the development and upgrading of Bitcoin is very pleasant and even eye-opening. In its upgrades, you can see that people are tirelessly using cryptography to continuously optimize this system-thanks to the modular nature of the system itself, these optimizations are real. Taproot is one of them.

I believe that the process of learning about Bitcoin (and Taproot in particular) will teach the reader what a real "cryptocurrency" is.

Taproot may be the most important upgrade in the history of Bitcoin, which will create the purest cryptocurrency in history-the currency that uses cryptography to the extreme, is the lightest, and has the most tenacious vitality.

footnote:

1. Bitcoin upgrade proposal Taproot technical explanation, https://www.btcstudy.org/2021/09/29/bitcoin-taproot-a-technical-explanation/
2. Bitcoin Wiki Smart Contract, https://en.wikipedia.org/wiki/Smart_contract
3. Master Bitcoin Chinese Version Chapter 7: Advanced Transactions and Scripts, https://github.com/tianmingyun/MasterBitcoin2CN/blob/master/ch07.md
4. Types of Bitcoin transactions - Part II Segwit, https://blog.susanka.eu/types-of-bitcoin-transactions-part-ii-segwit/
5. What is a Bitcoin Merklized Abstract Syntax Tree, https://www.btcstudy.org/2021/09/07/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast/
6. How Schnorr Signatures May Improve Bitcoin, https://www.btcstudy.org/2021/09/09/how-schnorr-signatures-may-improve-bitcoin/
7. Taproot: Privacy preserving switchable scripting, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html
8. Explain the impact of Taproot on privacy in plain language, https://www.btcstudy.org/2021/09/23/explain-like-im-not-a-developer-taproot-privacy/

Source: Orange Book

Disclaimer: Cointelegraph Chinese is a blockchain news information platform, and the information provided only represents the author's personal opinion, which has nothing to do with the position of the Cointelegraph Chinese platform, and does not constitute any investment and financial advice. Readers are requested to establish correct currency concepts and investment concepts, and earnestly raise risk awareness.