A glimpse into BIP-Taproot
BIP, also known as Bitcoin Improvement Proposal, is the very form that Bitcoin developers adopt to make almost all Bitcoin-related technical improvements and parameter adjustments. Any heavyweight BIP is prone to triggering heated discussions among Bitcoin developers and the whole community, and may even lead to disputes that split the community consensus. Should always keep an eye on the Bitcoin BIPs!
Let’s try to check out this new BIP, which has recently caused a bit more sensation, an idea officially kindled on GitHub by Pieter Wuille, a really prolific and highlighted developer from the Core.
The BIP, under the heading Taproot, was formally launched on GitHub only earlier this month. It was highlighted as a soft-fork based adjustment on consensus layer. This update, quite deep and underlying, is hence worthy of attention from Bitcoin enthusiasts.
As embodied in the description, this BIP is highly skilled and technical. Apart from explaining the motivation to further improve the privacy and efficiency of Bitcoin, several technical terms keep cropping up and catching our eye, to name just a few, Taproot, Schnorr signature, G’root, MAST, SIGHASH_NOINPUT, and Merkle Branch, rather arcane and exclusive for interpreting.
Let’s cut to the chase and go right to our concern. Taproot, in fact, is a technical solution to signing transaction scripts. Its most functional role is to homogenize, in a content perspective, the transaction output based on whatever Pay-to-PubKey or Pay-to-ScriptHash (P2SH). The result will be for the details of the Bitcoin transaction output difficult to distinguish by outsiders. To put this simpler, Taproot actually works to make Bitcoin transactions look exactly the same on the blockchain explorer and impossible to tell each from one another, which naturally guarantees Bitcoin with considerably very good privacy.
For Schnorr signature, a signature algorithm different from ECDSA, we will brief on it in the subsequent section.
MAST is an extending design for Bitcoin, which can be understood as adding a smart contract-like function to the existing system. The basic idea of MAST is to combine the original condition script Pay-to-ScriptHash (P2SH) with the Merkle Tree structure, so that logically more complex and flexible transaction scripts can be implemented in Bitcoin. What is more, MAST makes the transaction volume regarding various scripts to further shrink with privacy steadily enhanced, totally a comprehensive upgrade based on P2SH, period.
SIGHASH_NOINPUT, from a different approach, is a new OP_Code (Operation Code), set to address the signature sequence limit in transactions. In short, it enables users to finish signatures across sequences in multi-partied or multi-sig transactions. Also, this upgrade has brought about a crucial improvement in lightning network (LN) adaptability. The design of course has been also developed on the limitation of the Schnorr signature.
It appears clear at this time that that the Bitcoin BIP proposed by Wuille is actually a package of multiple upgrades, so ambitious and pointing right to the two fundamental weaknesses of Bitcoin — the insufficiency of privacy and the short of functional expansiveness. Yet, given the conservative and prudent style of Bitcoin upgrades, as they have always been, I believe that the whole developer community and Wuille (he himself professed) will really need a lot time to hammer out the final solution. So, it seems to be very likely that upgrades will be carried out in batches instead of being bound as a heavy package to be completed.
Core Technology: Schnorr Signature
As we above mentioned, this upgrade, though named Taproot, places the Schnorr signature algorithm at the heart underlying. All upgrades outlined in the BIP are basically binding measures based on the Schnorr signature scheme.
The Schnorr signature algorithm took its name from its inventor, Claus-Peter Schnorr. It is widely recognized by the cryptography community as a high-quality and reliable signature algorithm, known for its highly security, fast verification, non-malleability and signature aggregation. Its performance is somewhere as excellent as the ECDSA (Elliptic Curve Digital Signature Algorithm) adopted by Bitcoin from the very beginning of its inception.
More interestingly, the Schnorr signature algorithm and the Bitcoin white paper were born in the same year, both came into being in 2008. Thereafter, Pieter Wuille, the Bitcoin core developer mentioned above, and Greg Maxwell, a partner from Blockstream, Inc. worked together and proposed an enhanced version of the Schnorr signature algorithm to fit the Bitcoin application scenario. Certainly, it can be seen that the superior features of the Schnorr algorithm have already been on the radar of the keen Bitcoin developer community for a long time, not just a spur-of-the-moment thing of this year.
Among the most noteworthy features of the Schnorr signature algorithm is the Signature Aggregation. In Bitcoin scenario, if a transaction refers to multiple inputs, each of them will need to produce a signature under the ECDSA scheme. Yet if Schnorr is employed, all input signatures can be aggregated into just one. The Schnorr signature itself is more compact than the ECDSA, when coupled by the aggregation function, it can save considerable amount of transaction volume. Magic!
This is definitely a big plus for those complex Bitcoin transactions with multi-sig and conditional scripts, which in previous practices will require fairly cumbersome and complicated signature scripts. Thus, this upgrade is so far-reaching that it deserves in-depth analysis by Bitcoin researchers.
Probably the key Bitcoin update in the medium term
This upgrade is considered so profound and influential for Bitcoin as it points to the positioning of the Bitcoin development framework in the coming years.
The BIP, based on Schnorr signature, had directly packaged a number of functional upgrades and new operation codes. The content structure of transaction scripts had also been modified at an underlying level. For this reason, the form of Bitcoin transactions can be said to have been completely rewritten.
The high privacy enabled by Schnorr signature and its adaptability to multi-sig transactions have bestowed Bitcoin with stronger privacy and functional expansiveness in this BIP-led upgrade.
Bitcoin, however, has always been widely blamed for its short of privacy. We (and the whole market) have been talking about this time and time again. It is impossible for Bitcoin to hide all the elements of a transaction simply as such anonymous coins Monero and Dash will do. Otherwise, given that Bitcoin gains total anonymity (like Z-Cash), something too radical and absolutely out of the question. However, we can expect Bitcoin to enhance its privacy somehow at the transaction level and make the transaction information less straightforwardly exposed and not that easy to track. That’s enough for Bitcoin.
Also I have to mention that the new Schnorr signature does not come to throughly replace the ECDSA, which has been running for years and its reliability totally proven to the market; yet it opens a new window, an alternative scheme for users, at least in the near feature. For the Bitcoin ecology, this is just like an injection of fresh blood into the vein, presumably to activate the beliefs of the community and market for extended application scenarios.
In fact, BCH has ahead of all upgraded the Schnorr signature algorithm last month. The BCH community has also long begun to pay a closer look at the possibility of this upgrade. BCH seems to like to show the market something that BTC Core has been watching for way too long to really kick off. What a quick and wise snatch. If Bitcoin really succeeds in completing the upgrades, it will, in turn, promote the market recognition of BCH — after all, it is BCH (not BTC), that has steadily completed these long-awaited upgrades and proved their technical feasibility.
