Taproot is Wider than you Think
Original author: A Jian
The original article was published in The Orange Book with the title Bitcoiner.
Bitcoin's Taproot soft fork upgrade will be activated at Bitcoin block height 709632 (expected on November 15, 2021). This update contains a lot of important and wonderful content, but not enough attention in the Chinese-speaking world. This article will briefly introduce Taproot's upgrade from a technical point of view, and reflect the development direction of Bitcoin.
The common claim is that Taproot improves bitcoin's privacy, smart contract functionality, homogeneity, and so on. But to understand the Taproot upgrade's content and imagination, we need to know something about Bitcoin.
What many people don't know is that Bitcoin also supports programmatic smart contract 2, but the type of smart contract is different from that of other blockchains like Ethereum. Explaining this distinction in detail requires a special article, and it is not important in this article. Here are just a few common modules of bitcoin smart contract programming, for the convenience of everyone to understand their application scenarios:
As the reader can imagine, these modules seem simple enough, but the combination of possibilities is huge: multi-signature contracts define the rights of different parties and can be adapted to a wide variety of application scenarios, from corporate operations to household coffers; Time locks specify the permissions of different subjects in different periods of time. Multiple conditions significantly magnify the combined effect of these permission controls.
You can even make A contract that supports social recovery, with legacy effects, with just A few conditions: "I (A public key) can control the funds; If no one uses it for three months, I (B public key) and four friends, three of the five can control the fund together; My wife can control the funds if they are left unused for a year.
But for these contracts to actually work, two factors cannot be ignored: efficiency and privacy.
Efficiency means that bitcoin transaction fees are based on the volume of the transaction, with more conditional scripts taking up more space (in bytes) and higher transaction fees.
The privacy concerns are that script exposure will make others know that certain public keys are associated with each other, making it easier to identify the real identity of the public key owner.
Currently, bitcoin contracts are represented as a P2SH "address" (essentially a hash value). The script can be paid directly to the hash value of the script without being exposed when the contract is generated. However, when the money is spent, the script corresponding to the hash value must be fully exposed to the transaction (otherwise there is no way to verify that the hash value of the script is the hash value). In the case of a multi-signed contract, for example, someone else can pay directly for the hash value of the multi-signed contract script, but when a multi-signed contract participant wants to use the funds, the entire script must be made public 3.
In addition, before SegWit upgrade, single-signed personal wallet and contract wallet are clearly separated, the former is the P2PKH address, the latter is the P2SH address, which can be seen from the address alone, which is another unfavorable factor for privacy. After the SegWit upgrade, the personal wallet that supports segregated witness can also take the form of P2SH, but the native segregated witness address (P2WPKH) and the contract address (P2WSH) are still distinct 4.
With that in mind, let's take a look at how the three major parts of Taproot upgrades (MAST, Schnorr signature, Taproot) work better.
Merkle Abstract Syntax Tree (MAST)Merklized Abstract Syntax Trees (MAST) 5 is meant to support validation of Merkle evidence in script validation of Bitcoin.
Merkle trees are cryptographic methods of hashing multiple data elements into a single hash. The structure and the nature of the hash function dictate that some evidence (hash value) can be provided that a data element contributed to the generation of the hash value. As shown in the figure below, we hashed the (adjacent) data elements in pairs, eventually generating a Merkle root.

3

Individual Merkle proofs for Banana, Peach and Kumquat
As the smart reader might imagine, this feature allows contract writers to hash multiple conditions into different data elements to produce a Merkel-root value. When you need a condition to unlock a bitcoin, you just need to prove that the condition is in the Merkle tree, and you don't need to disclose all the other conditions.
Yes, that's what Masts do. As shown in the figure below, there are two conditions for unlocking this fund, and the authors have separated them, abstracting them into a hash using merkle trees, so that unlocking using either condition requires no disclosure of the other.

005.png
MAST is a big step forward from P2SH, where contracts required that all script content be made public, whether it was used or not. Now, with masts, users only need to expose the unlock conditions they need to use, rather than the whole thing; At the same time, people have no idea how many conditions you have left.
Second, it is more efficient: the user only needs to provide the part of the script that needs to be used, along with merckle evidence, which is very noticeable when the whole script is large.
As a result, future Bitcoin users will be able to write contracts with a wide range of conditions, gain better control and pay less in fees; You can even intentionally include some garbage conditions to fill out the Merkle tree for the benefit of privacy.
With Masts, even extremely conditional asset management scripts can be compressed into a single hash that exposes only a portion of the value when used. The cost reduction opens up a lot of possibilities for wallet developers to explore.
With the Taproot upgrade, bitcoin will support not only cryptographic signatures based on elliptic curves, but also Schnorr digital signature scheme 6.
The construction of a Schnorr signature is not mentioned here, but its important property: signature/key aggregation - a signature of multiple private keys that can be aggregated into a single signature that looks as if it were checked out by a single private key. When signing, it is still signed by each private key holder. The signatures are checked as if they were checked out by a private key corresponding to a known public key (which is, of course, the aggregated public key of the participants).
That is, with a Schnorr signature, it is impossible for others to tell whether a signature is signed by a single person or a group of people; The unlocking condition for multiple signatures can be replaced by an aggregate public key. All N-N multi-signature contracts can enjoy the privacy protection provided by Schnorr signatures. The most obvious application is lightning network channel, because lightning network channel is a 2-2 multi-signature contract; Since then, it has been impossible for others to distinguish between payment channels and individual users by the number of signatures.
As for m-N's multi-signature contracts, don't forget that we have MASts: we can convert all possible unlocking scenarios into a branch, and when we use a branch, the only signatures provided are aggregate signatures. For example, suppose that we need to do A 2-3 more signed the contract, in the public key of A and B, C three take A second, more than the signature contract effect is equivalent to "unlock (A, B), or (B, C), unlocked, or (A, C)", it can be understood as A condition more scripts, each condition is more than A 2-2 signatures, Therefore, the corresponding aggregation public key can be used to define the unlocking condition (instead of multi-signature definition). So when we need to unlock money in some combination, we just expose a branch with MAST and provide a signature, and people still don't know if it's one person, two people, or multiple people.
I'm not done yet.
In our way of thinking, the last part of the Taproot upgrade is Taproot, hence its name. In developing this concept, Gregory Maxwell wrote 7:
One oft-asked question in discussions of merkelisation scripts is whether we can achieve an elaborate contract indistinguishable from the most common and boring payments. Otherwise, an anonymous set of outputs using these trendy techniques, just another niche set, doesn't make much sense in practice.
Maxwell got to the point: Bitcoin's privacy is guaranteed because it is "hidden from the market", and it is better that all utXOs look the same, so that the real identity and true composition of the user is difficult to understand. However, when new features are introduced, a new type of "address" is inevitably introduced, and if the number of users using this feature is small, the likelihood of each user revealing their real identity is greatly increased, which may result in the new features not being used at all and thus becoming meaningless.
And while masts play a big role in the privacy of contracts, if it's as clear as it used to be that personal wallets are personal wallets and contract wallets are contract wallets, that privacy is still flawed.
There is an urgent need for a way to end the personal-wallet/contract-wallet divide and add some privacy to bitcoin. To achieve this, the minimum point is that the wallet with the contract, in the daily use of users, its cost is no different from ordinary personal wallet (economic).
Taproot is such an approach. It takes advantage of the characteristics of key aggregation and proposes a script pattern with two paths: one is n-N multi-signature contract; The other is a user-defined contract script.
Example: from Maxwell's original hypothesis two users with the public key of A and B, two people aggregate public key A + B = C, recycled into the final public key P = C + H (C | | S) * G, including S for custom scripts. The final public key P is used to define the conditions for unlocking funds. Assuming that the two users are online, they can easily use the money together, as long as one of the parties at the time of signature in their own private key with H (C | | S); If only one online, such as S defines B can spend money, Taproot rules make public key users can reveal polymerization public key P and B H (C | | S) and offer can satisfy the conditions of S to useGold.
The 2-2 multi-signature contract is used here, but the user can imagine that 1-1 (single signature) could also take advantage of this scripting approach as long as key aggregation techniques are available. The important thing is:
(1) Although this is a fund with a custom contract, the handling cost is no different from the fund unlocked by a single signature when n-N multi-signature is used without the contract!
(2) When using n-N multi-signature, others do not know that this fund can be unlocked in other ways!
In this way, individual users and contract users can be unified in one script mode (P2TR "address"), individual users can add contract to their funds without worrying about the daily cost of higher fees; Contract users and individual users enjoy a larger set of anonymity because they use the same "address," and in most cases do not even have to disclose their use of the contract. Everybody's happy.
In short, after Taproot, it will be impossible to tell whether a P2TR address is a personal user or a contract user from the address form; Due to the effect of Schnorr signature, when the funds in this address are unlocked using a single signature, others will not be able to tell whether it is used by one person or n people together, nor can they know whether there is a custom script for this address; Thanks to the MAST effect, when users spend money with custom scripts, only part of the script is exposed. Others know that there is a custom script for this address, but it is still unknown what conditions the script actually contains.
So while some question whether Taproot could in turn undermine bitcoin's privacy, 7 I'm not at all worried. Because Taproot "addresses" are undoubtedly the best in the history of Bitcoin in terms of convenience, privacy and economy, it has every hope of unifying the types of "addresses" of Bitcoin and forming the largest anonymous set in the history of Bitcoin.
For those who know something about cryptography, learning how to develop and upgrade Bitcoin can be enjoyable, even eye-opening. In its upgrades, you can see the relentless use of cryptography to improve the system -- and thanks to the modular nature of the system, the optimizations are real. Taproot is one of them.
I believe that learning about Bitcoin, and Taproot in particular, will teach readers what a "cryptographic currency" really is.
Taproot is probably the most important upgrade in Bitcoin's history, creating the purest cryptography currency ever created -- the lightest, most durable currency that takes cryptography to its extreme.
Thanks to @hou123, @Zeng for her instructive feedback on this article.
@ Bruce: For the ashes of a vicious cycle of U.S. monetary policy rhinos, part of the American political elite has realized that the currency is no anchor out of the value of the dollar or a choice, in order to let people and enterprises to the United States financial clearing the worst possibility to prepare, this article calls for us policymakers fully open the currency and the regulation of the digital assets, It has even suggested that the Treasury consider replacing a small portion of its gold holdings with bitcoin
@Damai: 100x Xiao Hei on "Crypto and Religion"
@Guo Yu: This article compares the different mechanisms of Arbitrarrum and Optimism using fraud proof to realize Rollup.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia