Taproot is wider than you think
Hash is the Bank
Bitcoin soft fork “Taproot” is scheduled for block height 709632 which should happen on November 15, 2021.
This article will briefly introduce the upgrade content of Taproot from a technical point of view, and thus reflect the development direction of Bitcoin.
The common saying is that Taproot has improved Bitcoin’s privacy, smart contract functionality, and homogeneity. However, in order to understand the content and imagination of Taproot’s upgrade, we must first understand Bitcoin.
Smart contracts on Bitcoin
What many people don’t understand is that Bitcoin also supports programming smart contracts, but the type of smart contract is different from other blockchains (such as Ethereum). A detailed explanation of this distinction requires a dedicated article, and this distinction is not important in this article. Here are just a few common modules of Bitcoin programming smart contract, 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, the private key (for the same operation) corresponding to the M public keys must be signed before 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 is absolute time lock, defined by a specific time or specific block height, and can only be used after this time;
(2) CSV is relative time lock, for example, the funds can only be used after 1000 blocks of the transaction that generated the funds are on the chain.
· Multi-condition programming
That is, use the “IF…ELSE…” type statement in the script to set multiple unlock conditions for the same fund, and the funds can be used when any one of the conditions 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 the YYYY blocks of the transaction on the chain, A. The private key 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, which can be adapted to extremely rich application scenarios, from company operations to family vaults. The time lock stipulates the authority of different subjects at different time periods. The multiple conditions significantly amplify the combined effect of these authority controls.
You can even make a contract that supports social restoration and inheritance distribution with only a few conditions. For example, if I (A public key) can control this fund, however, if no one uses it for three months, there comes another situation. Three out of I (B public key) and four friends can control this fund together. In addition, if no one uses it for a year, my wife can control this fund.
However, for these contracts to actually come in handy, two factors cannot be ignored: efficiency and privacy.
Efficiency means that the transaction fee for Bitcoin transactions is calculated based on the volume of the transaction. Scripts with more conditions will take up more space (in bytes), and transaction fees will also be higher.
The consideration of privacy is that the exposure of the script will make others know that certain public keys are associated with certain identities, making it easier to analyze the true identity of the owner of the public key.
At present, 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 be kept private, and if necessary, the hash value of the script is paid directly. However, when these funds are spent, the script corresponding to the hash value must be fully disclosed and put into the transaction, otherwise there is no way to verify that the hash value of this script is exactly this hash value. Take the multi-signature contract as an example, others can directly pay the hash value of the multi-signature contract script. However, when the participants of the multi-signature contract want to use these funds, the entire script must be made public.
In addition, before the SegWit upgrade, single-signature personal wallets were distinct from contract wallets. The former was a P2PKH address, and the latter was a P2SH address. It can be seen from the address alone that this is another factor that is detrimental to privacy. After the upgrade of SegWit, personal wallets that support SegWit can also take the form of P2SH, but the original SegWit address (P2WPKH) and contract address (P2WSH) are still distinct.
After understanding these, let’s take a look at how the three major parts of Taproot upgrade (MAST, Schnorr signature, Taproot) can do better.
Merkel Abstract Syntax Tree (MAST)
The meaning of Merkelized Abstract Syntax Trees (MAST) is to support verification of Merkel evidence in Bitcoin script verification.
Merkel tree is a cryptographic method that hashes multiple data elements into a hash value. The 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 the generation of the hash value. As shown in the following figure: We could continue to hash every two adjacent hashes, and finally generate a Merkel root.
Similarly, as shown in the figure below, when I want to prove that the red data “Banana” participates in generating the purple hash value (Merkel root), I only need to provide the red data and three green hash values, no need to expose the remaining 7 elements that co-produce Merkel root. This is the role of Merkel trees and Merkel evidence.
You might think that with this function, the contract writer can divide multiple conditions into different data elements and hash out a Merkel root value. When a certain condition is needed to unlock Bitcoin, at that time, you only need to prove that this condition is on this Merkel tree, and you don’t need to disclose all other conditions.
Yes, this is the magical effect of MAST. As shown in the figure below, there are two unlocking conditions for this fund, and the author divided them up and abstracted them into a hash value with a Merkel tree. When unlocked under any condition, they do not need to disclose another one.
MAST has taken a big step on the basis of P2SH, and its improvement effect is first reflected in privacy. Originally in P2SH, when the contract is used, all the script content must be disclosed, regardless of whether the content is used or not. But now, with MAST, users only need to disclose the unlocking conditions they need to use, instead of all content. In addition, others won’t be able to know how many conditions you have.
Secondly, it is also improved in efficiency. Users only need to provide part of the script that needs to be used, and their Merkel evidence. When the entire script is relatively large, the effect of this volume saving will be much more obvious.
As a result, future Bitcoin users can write contracts with many conditions, obtain better control effects and need to pay less fees. Even more, they can intentionally include some junk conditions to enrich the Merkel tree and improve privacy.
This is also the origin of the subtitle of this article “Hash is the Bank”. Bitcoin scripts actually all revolve around the control of funds. The key to achieving this control is multiple conditions, and with MAST, even if there are many conditions, the asset management script can also be compressed into a hash value, and only a part of it needs to be exposed when used. Cost reduction can open up many possibilities, I believe that wallet developers will find them out.
Schnorr signature
After the Taproot upgrade, Bitcoin will not only support elliptic curve-based cryptographic signatures, but also Schnorr digital signature scheme.
The construction method of Schnorr signature is not mentioned here and we will only discuss its important properties. Signatures of multiple private keys can be aggregated into one signature, which looks like it was signed out by a private key. When signing, it is still signed by each private key holder, however, while verifying, it seems that these signatures are a private key corresponding to a known public key which of course, is the public key formed by the aggregation of the public keys of these participants.
With Schnorr signatures, other people can’t tell whether all signatures are signed out by a single person or signed out by multiple persons together, because an aggregated candidate can be used for multi-featured field conditions. All of the multi-signature contracts can receive the privacy protection provided by Schnorr’s signature. Its most unique feature is the application of network traffic, because network traffic is a 2–2 multi-signature protocol, after that, other people cannot identify the number of signatures to distinguish between payment channels and individual users.
As for the m-n multi-signature contract, don’t worry, we have MAST contract, so that we can convert all possible unlocking situations into a branch, and when using a branch, the provided signatures only need to be aggregated signatures. For example, suppose we want to make a 2–3 multi-signature contract. Choose two of the three public keys A, B, and C. The effect of this multi-signature contract is equivalent to “either (A, B) unlock, or (B, C) ) Unlock or (A, C) unlock”, this can be understood as a multi-condition script, each condition is a 2–2 multi-signature, so the corresponding aggregate public key can also be used to define the unlocking conditions (and no need to define with multiple signatures). 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. Others still won’t know whether this is a single person, two people, or multiple people.
It’s not over yet.
Taproot
According to the path we understand, the last part of Taproot upgrade is Taproot, which is the origin of its name. When proposing this concept, Gregory Maxwell wrote:
When discussing Merkelization scripts, a question that everyone often raises is whether we can implement a sophisticated contract that makes it no different from the most common and boring payment. Otherwise, the anonymous set that uses the output of these fashionable technologies, which is just another niche set, is of little significance in practice.
Here, Maxwell has keenly grasped the main point of the problem: Bitcoin’s privacy protection comes from the “big hidden in the market”, and it is best that all capital units (UTXO) look the same, so that the user’s real identity and real composition is the most difficult to grasp. However, when introducing new functions, it is inevitable to propose a new type of “address”. If there are few users using this function, the possibility of each user revealing his true identity will greatly increase, and this may lead to the new function not being used at all, thus losing its meaning.
Moreover, although MAST plays a major role in the privacy of contracts, if personal wallets are personal wallets and contract wallets are contract wallets, as in the past, it then proves that this privacy is still flawed.
People desperately need a way to end this distinction between personal wallets/contract wallets and add the finishing touch to the privacy of Bitcoin. To this end, the most important thing to achieve is that this kind of wallet with a contract, in the daily use of the user, has the same cost (economical) as an ordinary personal wallet.
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 an n-n multi-signature contract; the other is a user-defined contract script.
Following the example from Maxwell’s original text:
Assuming that two users have public keys A and B, they 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. Just use this final public key P to define the unlocking conditions of the funds.
Assuming that two users are online, they can easily use the funds together, as long as one of them adds H(C||S) to their private key when signing;
If only one of the parties is online, for example, S defines the conditions under which B can spend funds, Taproot’s rules enable users of public key B to use funds by revealing the aggregate public key P and H(C||S) and providing conditions that can satisfy S .
Here is a 2–2 multi-signature contract used above, but as long as the key aggregation technology is available, 1–1 (single-signature) can also use this scripting method. The important things are:
(1) Although this is a fund with a custom contract, when the contract is not used and only n-n multi-signature is used, the handling fee cost is no different from the funds unlocked by a single signature!
(2) When using n-n multi-signature, others do not know that the funds can be unlocked and used in other ways!
In this way, both individual users and contract users can be unified under a script mode (P2TR “address”), and individual users can add contracts to their funds without worrying about daily higher transaction fees. Contract users and individual users enjoy a larger anonymity set because they use the same “address”, and in most cases they don’t even need to reveal their use of the contract. Everyone is happy.
All in all, after Taproot upgrade, others will not be able to distinguish 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 distinguish it. Whether it is used by one person or by n people together, it is impossible to know whether this address has a custom script; due to the effect of MAST, when users use a custom script to spend funds, only the parts that need to be used are exposed in that script. Although others know that this address has a custom script, it is still not known what conditions are included in the entire script.
Therefore, although some people question that Taproot might in turn bring damage to the privacy of Bitcoin, I am not so worried at all. Because Taproot “address” is undoubtedly the best in Bitcoin history in terms of convenience, privacy, and economy. It is entirely hopeful that it can unify Bitcoin’s “address” type and form the largest anonymity set in Bitcoin history.
Conclusion
For those who know some cryptography technology, learning the development and upgrade of Bitcoin is very pleasant, and even an eye-opening experience. In its upgrade, you can see people tirelessly using cryptography to continuously optimize this system, thanks to the modular nature of the system itself, these optimizations are real and sensible. Taproot is one of the representatives.
I believe that the process of learning Bitcoin (especially Taproot) will tell readers what the real “cryptographic currency” is.
Taproot may be the most important upgrade in the history of Bitcoin, and it will create the purest cryptocurrency in history-a currency that utilizes cryptography to its extreme, lightest weight and most tenacious vitality.
