This article based on report Kraken Intelligence, we present to the reader's attention a detailed review updates to Taproot, how it works and why it matters to the future of Bitcoin.
- What is Taproot
- The origins
- Chronicle of activation
- Why is it important
- How Bitcoin Transactions Work
- Public key cryptography
- Bitcoin wallet components
- Bitcoin's unspent output (UTXO) model
- Bitcoin scripts
- Transaction codes
- P2PKH (Pay-to-Public-Key Hash)
- P2SH (Pay-to-Script Hash)
- Public key cryptography
- BIP340 (Schnorr circuits)
- BIP341 (taproot)
- MAST (Merklized Alternative Script Trees)
- P2TR (Pay-to-Taproot)
- BIP342 (tapscript)
- Impact of Taproot
Many people call Bitcoin the most important invention sincesince the advent of the Internet in 1983. But despite the revolution, Bitcoin has certain limitations that have hindered its mainstream adoption until now, including scalability and privacy issues. Historically, the optimization of the Bitcoin protocol has been a continuous process of exploring new ideas and building consensus on them within the community. However, reaching consensus is cumbersome and infrequent, and there has been considerable disagreement among Bitcoin's vast and diverse user base over the future path of Bitcoin. There's no need to look far for an example: The last bitcoin update before Taproot was the Segregated Witness (SegWit) soft fork, which split the community and led to the hard fork that formed Bitcoin Cash (BCH).
Bitcoin's new big update known asTaproot, activated on November 14, 2021, is made up of three major Bitcoin Improvement Proposals (BIPs) that implement several technical solutions to improve privacy, security, and network scalability. BIP340 (Schnorr Scheme) updates the underlying Bitcoin cryptography by integrating support for the lighter and more secure Schnorr digital signature scheme in addition to ECDSA traditionally used in Bitcoin. BIP341 (taproot) builds on the SegWit update to improve network privacy, lower transaction fees, and expand the capabilities of Bitcoin scaling solutions such as the Lightning Network. Finally, BIP342 (tapscript) integrates a reformed version of the Bitcoin scripting language to provide full support for Schnorr signed taproot transactions and facilitate future Bitcoin updates.
Together, these changes will allow records ofstandard single-sig signed transactions, multisig transactions and complex smart contracts look indistinguishable from each other on the blockchain. Thus, Taproot significantly improves user privacy, network scalability, and the interchangeability of all bitcoins. Users are able to execute multi-signature transactions and create complex smart contracts with the same efficiency, low fees and privacy as regular single-sig transactions. Taproot is arguably the most significant Bitcoin update to date and sets the stage for further innovation and adoption. Anyone who understands its intricacies will gain a deep understanding of what this revolutionary technology has to offer the world. In this post, based on a Kraken Intelligence review, we bring to the reader's attention a comprehensive analysis of the Taproot update, how it works and why it is important for the future of Bitcoin.
What is Taproot
Taproot is a soft forkan update to the Bitcoin protocol, combining a number of technical solutions that will make Bitcoin transactions more private, flexible and scalable. Taproot consists of the following three Bitcoin Improvement Proposals (BIPs):
- BIP340 (Schnorr scheme)
Traditionally, Bitcoin has used the Elliptic Curve Digital Signature Algorithm (ECDSA), an application of public key cryptography to authenticate transactions.
BIP340, in addition to ECDSA, will add to BitcoinSchnorr signature scheme support. It is also based on a mathematical structure called an elliptic curve. Elliptic curves from algebraic geometry are used in various public key cryptographic systems as the basis for some of the most secure encryption protocols. An elliptic curve consists of all points that satisfy the simple equation “y2 = x3 + ax + b”. The functions defined by the elliptic curve are easy to perform, but almost impossible to invert.
We wrote more about the mathematical foundations of Bitcoin cryptography in the following articles:
- Bitcoin Math: Theory
- Bitcoin Math: Practice
The diagram below shows that the public keys anddigital signatures represent points on an elliptical curve, although signatures are not limited to a point on an elliptic curve. If both of these points are created from the same private key, then the geometric relationship between them proves that the person who created the digital signature also owns the public key. ECDSA is essentially a mathematical way of verifying ownership of bitcoins without providing access to the bitcoins themselves or any other private information.
The Schnorr scheme has several important advantages over ECDSA: it is more secure, non-plastic, and helps lower transaction fees.
We covered the topic of Schnorr signatures, in particular, in these posts:
- Signatures of Schnorr
- The Power of Schnorr: Improving Bitcoin Scalability and Privacy
The Schnorr scheme opened the door for the implementation of BIP341 (taproot), which means that without its implementation in Bitcoin, the Taproot update would not have been possible.
- BIP341 (taproot)
Adds Taproot support to the Bitcoin protocol,a solution that enhances the privacy of bitcoin transactions and uses the Schnorr scheme to implement Merklized Alternative Script Trees (MAST). MAST relies on hash trees (a structure used to verify and synchronize data) and enhances the efficiency and privacy of smart contracts by only revealing conditions that have been met and keeping any other conditions that existed secret.
- BIP342 (tapscript)
Adds support to the Bitcoin protocolTapscript, an updated scripting language that complements the Schnorr and Taproot signature schemes. Tapscript improves signature hashing for validating taproot scripts, provides the flexibility to extend Bitcoin smart contracts, and modifies some resource constraints, including removing the 10,000 byte size limit that exists in legacy scripts. Tapscript provides a future compatibility mechanism known as tagged public keys, making it easier for future soft forks to extend signature verification opcodes with new signature hash types and other possible changes.
Overall, one of the main options of the Taproot soft forkis to make multi-party signed transactions and complex smart contracts indistinguishable from simple transactions by aggregating keys. As a result, the records in the blockchain of even the most complex smart contracts and ordinary transactions will be almost identical. Thus, the signature aggregation method used in Taproot can increase privacy, including the Lightning Network, due to the fact that transactions for opening and closing lightning channels will look indistinguishable on the Bitcoin blockchain from ordinary one-way signature transactions. In addition, Taproot helps reduce transaction fees - directly for multisig transactions and indirectly for all users by allowing the same volume of transaction confirmation demand to be satisfied using less block space.
As we will discuss further in this review,The importance of key aggregation should not be underestimated, as it effectively allows complex second layer Bitcoin-based networks to create huge (for example, over a thousand signatures) vault contracts that were simply not viable before.
- Taproot: what it is and how it is useful for Bitcoin
More about Lightning Network:
- What is Lightning Network
- Lightning Network Analysis - Available Metrics and Existing Vulnerabilities
Taproot development started for almost four yearsback after former Blockstream CTO and renowned Bitcoin Core developer Gregory Maxwell proposed the concept of mitigating Bitcoin's scalability, privacy and security concerns in January 2018. In September 2019, Bitcoin developer Pieter Wuille proposed implementing Taproot in Bitcoin Core. Shortly thereafter, the Taproot update began to pick up steam. Between November 3 and December 21, 2019, the proposal was reviewed and tested by 150 developers.
Chronicle of activation
Update consensus with supportthe vast majority of stakeholders was confirmed on June 12, 2021, at the end of the third signaling period, at block 687 284. On November 14, 2021, at block 709 632, the Taproot soft fork was activated.
Why is it important
Protocol updates are rare becauseBitcoin is an iterative technology with financial risks. The code of any update may contain errors or lead to unforeseen consequences. Reaching a network consensus on updates also generally requires the update to be backward compatible and have only minor compromises on resource requirements for software clients of bitcoin nodes. As a consequence, developers need to have sufficient time to thoroughly test the code of proposed updates.
In addition, due to the decentralized natureBitcoin, to properly implement the update of the general consensus rules requires careful coordination of many network participants around the world. Making changes to the Bitcoin protocol is difficult because the network does not have a central governing body to decide which changes are appropriate to adopt, and many key stakeholders often disagree.
In particular, SegWit, which served as the basis forThe appearance of the Lightning Network has become an extremely controversial update as a number of organizations have tried to link those changes to the network's hard fork proposal.
SegWit solved the problem of plasticity of transactions andincreased the scalability of Bitcoin. You can read more about this, for example, in this post, and here I would like to draw your attention to the fact that the question of scaling methods has caused heated debate in the Bitcoin community about whether it is necessary to simultaneously increase the allowable block size in order to increase the number of transactions processed, or this will damage the decentralization of the network, significantly increasing the cost of maintaining its full nodes. Subsequently, this debate turned into a full-fledged “civil war” in the community and led to a hard fork that created Bitcoin Cash - a fork for those who wanted a larger block size version of Bitcoin.
Unlike SegWit, of the same name with TaprootNobody tried to impose a hard fork, the support from the miners was quite significant and this proposal practically did not cause conflicts in the community, implying that the community, as a whole, agrees that Taproot is a significant improvement for Bitcoin. The difficulty was the choice of the optimal activation method, taking into account the experience of the previous update.
Although it may seem smooth andWith incremental improvements, Taproot is revolutionizing Bitcoin and its capabilities by dramatically improving its privacy, making its units of account more interchangeable, improving network scalability, and setting the foundation for easier deployment of future changes. At a high level, Taproot enhances Bitcoin's efficiency as a medium of exchange by increasing its bandwidth, modernizing the underlying cryptography that keeps the network secure, and inspiring more developers to create new Bitcoin-based solutions, including, but not limited to, the ability to create sophisticated DeFi smart contracts. Ultimately, Taproot will help improve the user experience with Bitcoin and accelerate the development of related innovations.
How Bitcoin Transactions Work
In order to better understand whichchanges are made by Taproot and how they will work, you first need to get a fundamental understanding of how bitcoin transactions generally function. Those who are familiar with this topic can safely move on to the next part.
Public key cryptography
Bitcoin wallets resemble bank accounts inthat in order to access the funds stored in them, it is necessary to know the "account number" and "password". When a user creates a wallet, he randomly generates a unique cryptographic key pair, consisting of one public and one private key required to send and receive bitcoins. The public key acts as an "account number" and the private key acts as a "password". This scheme is called public key cryptography and its appearance in 1976 laid the foundation for the creation of the Internet, and now cryptoassets.
For beginners, I recommend reading these related articles:
- Cryptography for absolute beginners
- How does Bitcoin work? Dive into technical aspects
Here, in addition to these articles and perhaps a slightly more substantive illustration, I will list the 4 main components of a Bitcoin wallet.
Note: all values below are for illustrative purposes only; please do not send anything to this wallet or try to use it as your own!
Bitcoin wallet components
Using any Bitcoin wallet starts withseed phrases. It is usually a list of 12-24 words that you can use to back up and restore your wallet. Anyone who knows the seed value for your bitcoin wallet can withdraw funds from it, so it is extremely important to keep it secret and preferably not stored on a device with open access to the Internet.
An example of a seed phrase:
valley pulp iron unique pen tired energy crash topic business happy feel
- Private key
From this seed, the wallet generatespublic and private keys. A private key is a randomly generated large number used as a wallet password when using bitcoins. However, this number is so large that it is written in hexadecimal format (a combination of letters A – F and numbers 1–9) to make it more compact and easy to use. Based on the private key, you can create a unique digital signature that is used to transfer funds for storage to another digital wallet.
An example of a Bitcoin private key:
- Public key
Bitcoin's public key is a hexadecimal number derived from the private key. Usually the public key is used as the account number for receiving bitcoins.
An example of a Bitcoin public key:
Bitcoin wallet creates addresses by hashingpublic key - to shorten it and make it somewhat easier to use. The hash function takes the public key data, scrambles it, and returns a unique shortcut. This output value acts as a fingerprint for the public key data passed to the hash function. The wallet address can be shared with other users to “receive” bitcoins.
An example of a bitcoin address:
Bitcoin's unspent output (UTXO) model
“Let's define an electronic coin assequence of digital signatures. The next owner sends the coin to the next one by signing the hash of the previous transaction and the public key of the future owner and attaching this information to the coin. The recipient can check each signature to confirm the correctness of the entire chain of owners ", -
Satoshi Nakamoto explains the UTXO model in Bitcoin Whitepaper (2008).
UTXO stands for Unspent TransactionOutput (unspent transaction output). Bitcoin uses a non-spent outputs model to distribute digital “coins” to users. In other words, the UTXO model for Bitcoin is a way to organize the blockchain in such a way that users cannot spend the same coins twice. By the way, it was in the solution of the problem of double spending that the revolutionary technology of Bitcoin was in many respects.
Basically, each UTXO is the number of bitcoins,linked by address to a specific public key. Bitcoin transactions are made up of inputs and outputs; inputs are UTXOs consumed (and destroyed) in this transaction, and outputs are new UTXOs (tied to recipient address) created in this transaction. Since only unspent outputs can be used as transaction inputs, each UTXO can only be spent once. A transaction in which the sender tries to consume output that has already been used in another transaction will be rejected by the nodes (nodes) of the network as invalid.
For a detailed description of the unspent outputs model, I recommend referring to this article:
- Bitcoin UTXO Model
And here I will limit myself an example of a standard bitcoin transaction:
- Alice owed Boris ₿0.02 for repairing the car.
- Boris sends Alice his wallet address to receive the payment.
- Alice uses her private key to create a digital signature to unlock and send ₿0.02 from UTXOs controlled by her wallet to Boris's wallet address.
- Suppose there are only two UTXOs in Alice's wallet, worth ₿0.01 and ₿0.015. In such a case, both of these UTXOs are used as transaction inputs.
- Two new UTXOs are also created as transaction outputs: one, at ₿0.02, is tied to Boris's wallet, and the second, at ₿0.005, is received by Alice as change.
UTXOs are encoded in Bitcoin Script, the languagedeliberately constrained programming designed to describe UTXO spending rules for Bitcoin software clients. When they submit a transaction, users apply specific blocking scripts to each of the UTXOs created in that transaction. The recipient, when decides to spend these UTXOs, will have to execute the unblocking script that meets the specified conditions.
Scripts include two elements:
Any information required to complete a transaction - for example, a digital signature and a public key.
Operation codes (opcodes)
These are simple functions (like commands),operating with script data. Opcodes define the instructions that are recorded with each complex transaction, allowing users to set different spending conditions for the UTXOs created in a transaction.
When hosts confirm that the complete scriptvalid (i.e., all specified conditions for blocking and unblocking outputs are met), UTXOs are unblocked and can be spent. Signature verification to confirm ownership of the UTXO is required on every transaction, and some possible additional expense conditions include:
- multilateral signature (multisig): requires the provision of digital signatures from several specific private keys;
- hashlock: Requires the disclosure of a specific piece of data;
- timelock: Requires a certain block height or date to be reached.
For each transaction, you can usemultiple conditions, thus creating complex smart contracts. For example, when Alice sends Boris ₿0.02 to repair a car, Boris can apply additional spending conditions (multi-signature or temporary blocking) to these UTXOs before he can spend them. There are many different blocking scripts with different combinations of opcodes, but most nodes rely on several "standard" scripts: Pay-to-Public Key Hash (P2PKH), Pay-to-Script Hash (P2SH), and SegWit versions of these scripts - Pay- to-Witness Public Key Hash (P2WPKH) and Pay-to-Witness Script Hash (P2WSH). Descriptions for each of them are available on the links.
Pay-to-Public-Key Hash (P2PKH)
In most standard Bitcoin transactionsa P2PKH script is used to bind bitcoins to a hash (i.e. a compressed version) of the public key. Basic transactions sent to the address contain a P2PKH script that is resolved by sending the public key and the corresponding digital signature. However, since in P2PKH all spending conditions are publicly disclosed on the blockchain, complex transactions using different opcodes require more complex scenarios to preserve user privacy.
Pay-to-Script Hash (P2SH)
P2SH is a standardized smart contractBitcoin is more flexible than P2PKH as it allows users to create arbitrary scripts and multisignature transactions. In complex transactions with various opcodes, P2SH is usually used to maintain confidentiality, since the conditions for spending the transaction are not initially visible to an outside observer. Unlike a P2PKH script that blocks bitcoins based on the hash of the public key, P2SH blocks bitcoins based on the hash of the script itself. This means that outputs blocked by P2SH can only be provided with a script hash. And since initially only the hash of the script is included in the blockchain, the conditions for spending UTXOs are known only to their new owner.
Although initially the conditions for spending outputs inP2SH scripts are hidden from outside observers, the entire script with all the terms of spending is revealed when the UTXO is spent by the new owner. In addition, P2SH requires knowledge of the public keys of all participants in a multisig transaction, which is ineffective. Since the initial hash of the script can be used to confirm the validity of the script, this disclosure of all spending rules is a "feature, not a bug". However, this is due to the use of large amounts of data and breaches of confidentiality.
Blockchain analytics based on the on-chain trace of suchscripts can receive private information about users, such as the type of wallet used to complete the transaction. In addition, the conditions of such scripts, when exposed, allow observers to easily distinguish between standard P2PKH transactions and multisignature transactions. In a worst-case scenario, an enterprising attacker could even use this personal information to trick users or hack into their wallets. In addition, such a surplus of opcode data hinders network scalability by consuming more block space.
P2SH transactions are easily distinguishable from the rest,because they, according to BIP13, require a different type of address, starting with "3". This not only makes it easy to identify P2SH transactions, but also narrows the search for likely participants in a multisig transaction. P2SH does not appear to be a good long-term solution in terms of operational efficiency due to existing privacy and security concerns.
BIP340 (Schnorr circuits)
Bitcoin uses digital to transfer coinsECDSA signatures. However, the first phase of the Taproot soft fork will allow, in addition to ECDSA, the use of Schnorr signatures. Both schemes use elliptical cryptography, which uses elliptic curves to encrypt data, so that the encrypted data is easily authenticated, but nearly impossible to access without a "decryption key". For context, a Universal Security study (PDF) showed that breaking a standard 228-bit elliptic cryptography key would take more energy than boiling all the water on Earth.
Bitcoin uses elliptic cryptography toconfirmation of ownership of private keys by digital signature, without disclosing the private key. Although the fundamentals of public key cryptography have remained largely unchanged since its inception, there are dozens of open source signature schemes available to cryptographers around the world today.
Implementing support for Schnorr signatures not onlywas a prerequisite for the implementation of Taproot, cryptographers and veterans of the bitcoin community all agree that the Schnorr scheme outperforms ECDSA in almost every way and with little or no caveat. Some of the advantages of the Schnorr scheme over ECDSA include:
- Linear verification algorithm
Most Significant Advantage of the Schnorr Schemebefore ECDSA lies in its linearity, which is the basis for higher-level smart contracts, more efficient and confidential. This feature allows multiple parties to a multisig transaction to combine their public keys into a single signature valid for the sum of those public keys. This is called key aggregation. Combining public keys and signatures into "Threshold Public Keys" and "Threshold Signatures" shortens the process of verifying transactions. Namely, the network needs to verify only one key instead of several, which significantly reduces the size of multisig transactions and makes them indistinguishable in the blockchain from any ordinary transaction.
- Faster checkout
In addition to speeding up verification bylinearity, the signature scheme also modifies the opcode for Tapscript (OP_CHECKSIG) to expect Schnorr signatures instead of ECDSA. In addition, Schnorr Transactions will replace the ECDSA opcode family used to validate multisig transactions (OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY) with one more efficient opcode (OP_CHECKSIGADD). The new opcode improves the efficiency of signature verification by allowing transactions to be verified in batches rather than individually, and requires fewer opcodes for multisig transactions. As a result, Bitcoin users will have more efficient use of block space, allowing the network to process more transactions per second.
- High economic density
Schnorr signatures and public keys by about 11% and3% less than ECDSA signatures and public keys, respectively. The relative lightness of the Schnorr scheme allows the network to free up block space and scale more efficiently. This contributes to lower transaction fees for Bitcoin users in view of reducing the load on the network.
- backward compatibility
Schnorr signatures cause no problem withstandardization as they are compatible with ECDSA private keys. That is, those who use the Schnorr scheme will not have a problem with the fact that they will not be able to complete a transaction due to the fact that the recipient's wallet was created using ECDSA, and vice versa. Updates to the Bitcoin network as adopted by network participants need to be backward compatible because exchanges, custodian services and wallet operators will take some time to implement the necessary changes. If BIP340 (schnorr) were not backward compatible, it would be difficult and perhaps even impractical for service operators to implement support because it would make Bitcoin harder to use. For example, senders of transactions would have to sort out what software the recipients are using to avoid accidentally losing coins. Fortunately, BIP340 solves (or rather simply does not create) this problem by allowing transactions to be signed with ECDSA keys.
- Ensured security
Schnorr signatures are provably secure becausecontain easily verifiable proof of security. In contrast, the reliability of ECDSA signatures has only been proven in practice. While none of the attacks have successfully compromised ECDSA, no formal proof of the security of this encryption scheme has yet been presented.
David Poincheval (aka David Pointscheval) and JacquesStehr proved in a 1998 paper (PDF) that Schnorr signatures cannot be spoofed in message selection attacks (eg SUF-CMA). And this ensures that the only way to crack Schnorr signatures is to solve a virtually insoluble mathematical equation known as the elliptic curve discrete logarithm problem (ECDLP). On the other hand, the best results for confirming the safety of ECDSA are based on strong and tried-and-true assumptions rather than rigorous evidence.
While Schnorr signatures have many advantages overcompared to ECDSA, this scheme is not a new word in cryptography. German cryptographic scientist Klaus-Peter Schnorr invented this scheme when he was a professor at Goethe University in Frankfurt in the 1980s. However, Schnorr was jealous of his invention. The cryptographer patented his digital signature scheme, limiting its use and slowing down further innovation. The patent expired in 2008 when Satoshi Nakamoto invented Bitcoin. Since Schnorr has patented his signature scheme for nearly 20 years, most of the innovation has been around the open and free ECDSA scheme. At that time, Schnorr signatures were not used, standardized, and tested in a real-world environment to protect a global monetary system like Bitcoin. In general, Satoshi chose ECDSA over Schnorr in 2008 for several reasons:
- Lack of patents
Unlike the Schnorr scheme, ECDSA was not encumbered with patents or copyrights, which means there were no legal restrictions on its use on the Bitcoin network.
Since ECDSA has not been protected by a patent orcopyright, it was already familiar and familiar to most cryptographers. In addition, there was a consensus at the time that since the safety of ECDSA has been sufficiently proven by years of rigorous testing, it probably also has a longer remaining lifespan.
ECDSA was part of OpenSSL, a suite of toolsopen source encryption developed by cypherpunks to enhance the privacy of online communications. OpenSSL originally made the implementation of ECDSA in Bitcoin a relatively straightforward process.
Despite the known shortcomings of ECDSA andregularly criticized by cryptographers, it was an open, lightweight, reliable and trustworthy signature scheme. Compared to other popular alternatives, ECDSA was the optimal choice for digital money because it required less computing power, had a shorter key length, provided about the same level of security and was in line with industry standards. When implemented in Bitcoin, ECDSA has made some improvements from the start. For example, Pieter Wuille and his colleagues developed a Bitcoin-specific elliptic curve (known as secp256k1) that made signatures faster and easier. However, ECDSA inevitably has some drawbacks, and this justifies an upgrade of the entire system.
If BIP340 details the implementation inBitcoin's Schnorr scheme, the BIP341 describes the rules for a new type of outputs, P2TR (Pay-to-Taproot). P2TR is an upgrade from SegWit version 0 (i.e. P2WPKH and P2WSH) to version 1, which allows the use of Schnorr signatures. BIP341 aims to improve the privacy, efficiency, and flexibility of Bitcoin scripts without compromising network security.
BIP341 uses Schnorr signatures to implement more complex types of transactions that look indistinguishable on the blockchain from standard single-sig signed transactions:
- combines P2PKH and P2WPKH (single-sig transactions);
- Lightning channel opening / closing transactions, atomic swaps and other complex smart contract protocols;
- transactions using MuSig, a new, improved protocol for aggregating public keys and signatures for the Schnorr digital signature algorithm (similar to P2SH and P2WSH multisig transactions).
Non-P2TR transactions such as P2PKH and P2SH, whenexecution discloses all possible conditions for the execution of the transaction, including those that were not involved. As mentioned above, this increases network load and significantly reduces user privacy. Taproot allows you to theoretically scale any P2TR Bitcoin smart contract to the size of, for example, a decentralized autonomous organization (DAO) with 10,000+ participants and thousands of bitcoins blocked in the contract, while this contract will look and cost like a standard one-way signed transaction.
Imagine, for example, that at the entrance to a bar you needprove your age with some kind of identification ID. However, this will also reveal other personal information that is completely irrelevant to the situation: home address, TIN, organ donor status, visual acuity, etc. I think that most people will agree that it would be better to confirm at the entrance only age without revealing everything else. With bitcoin transactions of the old type (legacy), the situation looks approximately the same: to confirm a transaction, only the possible expense conditions that were fulfilled by the sender are important, but everything is published. Taproot solves this privacy issue with its Merkelized Alternative Script Tree (MAST).
To better experience the benefits of implementationTaproot, remember how on April 21, 2021, the average Bitcoin transaction fee hit an all-time high of $ 62.79. The transaction queue in Bitcoin's mempool has surged to its highs since the peak levels of the 2017 rally. This spike in transaction fees ended up dropping the price of bitcoin by 37% in five days. If taproot had been activated and widely used even then, the mempool would probably have been less congested, and transaction fees would have been lower; this could potentially allow any transactions to be reasonably performed regardless of the amount transferred.
MAST (Merklized Alternative Script Trees)
BIP341 implements MAST support in Bitcoin,using hash trees to solve the privacy problem of P2SH and P2PKH, which reveal all the conditions for the consumption of its outputs, including those that are not used, when a transaction is executed. Ralph Merkle, one of the inventors of public key cryptography and who invented cryptographic hashing, patented the concept of Merkle trees (also called hash trees) for a period from 1979 to 2002. A hash tree is an effective way to prove the presence of some data in a set without knowing the whole set. A hash tree is a tree-like data structure in which each leaf node contains a hash of a data block, and each non-leaf node contains a hash of its child nodes. Leaf nodes can have exactly one "parent" and no child nodes, that is, it is always the last element of each "branch". Nonleaf nodes have two parents and can have any number of child nodes.
Hash trees are used by major blockchains- Bitcoin and Ethereum - for efficient and secure verification of the content of large data structures, their integrity and consistency, as well as for data synchronization. The largest networks prefer hash trees over other data structures, because they are:
- significantly reduces the amount of data that must be maintained by the trusted party to confirm the integrity of the data;
- Uses less block space for simplicity and speed of computation;
- does not require transmission of any other information in excess of the minimum required to the network when confirming, separating the verification of the data from the data itself.
MAST only requires the disclosure of the completedUTXO consumption conditions, instead of expanding the entire script, including all non-activated conditions. This solution minimizes the amount of opcode data disclosed on-chain when UTXOs are created or consumed, while simultaneously reducing the size of each transaction, lowering fees and increasing user privacy. The scripts are organized into a MAST data structure for easy access. MAST is based on the idea that even the most complex smart contracts with multiple participants can include one condition, upon which all participants agree to complete the transaction.
MAST allows you to hash each separatelythe condition for the consumption of a set of UTXOs, instead of combining them into one hash, and building a tree structure from these hashes. This hash tree then produces a single root hash for the entire tree, which “locks” the UTXO. When expanding any data, the root hash and tree path can be used to check if that data has been included in the hash tree, while all other conditions that may be contained in the hash tree remain hidden.
MAST increases privacy and is more efficientuses data than P2SH smart contracts. And Schnorr signatures allow these MAST structures to be indistinguishable from standard Bitcoin transactions on the blockchain. As you can see in Figure 7 below, the amount of space occupied in a block by a multisig transaction is proportional to the number of its signers. However, when using P2TR multisig transactions have a fixed size, so they can have almost any number of signers and at the same time "weigh", look and cost exactly the same as P2TR transactions with a one-way signature.
As stated above, BIP341 (taproot) implementsin Bitcoin, support for a new type called Pay-to-Taproot (P2TR). This type of script allows outputs to be consumed by using a single Schnorr signature to spend by key, or by expanding and satisfying the requirements of one of the scripts in the hash tree. The P2TR script combines two traditionally separate spending policies: P2SH and P2PK, which is similar to P2PKH, but differs in that it binds bitcoins to the public key itself, and not to its hash. As a result, all P2TR outputs can be spent either by public key or by script, and they become indistinguishable from each other. P2TR is the native output of SegWit v1.
Learn more about Pay-to-Taproot (P2TR) includinga visual diagram can be found in the glossary of terms. And to better understand the potential impact of taproot, it's also helpful to take a look at the most common way of transferring capital on the Bitcoin network: one-way signed transactions.
Cost of creating and spending taproot outputwith one-sided signature (SegWit v1) is about 5% higher than when using P2WPKH (SegWit v0). However, the cost of creating a taproot output is almost equal to the cost of creating a P2WSH (multisig) output, while consuming a taproot output with a one-way signature is 40% cheaper than P2WPKH. That is, while P2WPKH is somewhat more efficient than P2TR for one-way signed transactions, P2TR makes multisig transactions look indistinguishable from standard single-sig transactions.
The third phase of the soft fork called Tapscript(BIP342), defines small changes to the Bitcoin scripting language for use with P2TR transactions. As discussed above, the traditional Bitcoin scripting language, simply called Script, is used to define policies for spending digital "coins". Similarly, Tapscript defines the semantics of the spend terms for Taproot, making Schnorr signatures and Taproot technology available to users.
As an updated version of the Bitcoin Script language,Tapscript makes it easy to introduce new features and builds on the ability to batch verify Schnorr signatures. Specifically, Tapscript improves signature hashing for validating taproot scripts, adds new opcodes to allow users to create more complex smart contracts, and changes some resource caps, including removing the 10,000 byte data size limit and the number of opcodes in the transaction. In addition, Tapscript shares most of the opcodes with legacy (ECDSA) and segwit transactions, with a few exceptions:
- The signature verification opcode in Tapscript does the verification of Schnorr signatures, not ECDSA.
- Two opcodes previously used for verificationsignatures in multisig transactions are replaced with a single opcode in Tapscript, allowing batch verification of Schnorr signatures and reducing the number of opcodes required to perform existing tasks such as verifying signatures.
- The new opcode used to update the language system makes it easier to introduce new opcodes in the future.
- Signature hashes (SIGHASH) indicating whichparts of the transaction are digitally signed, calculated differently than in traditional Script or SegWit, to facilitate the expansion of signature verification opcodes with new types of "sighashes" or other changes in future soft forks.
While Tapscript may seem like only smallhelp to implement support for Schnorr and Taproot circuits, this is an important piece of the puzzle. Traditionally, signature verification has been the most resource-intensive operation, since signatures are verified individually. The introduction of batch verification of Schnorr signatures allows Bitcoin to realize the efficiency improvements unlocked by the implementation of Schnorr signatures and Taproot. And a new level of flexibility in Bitcoin smart contracts, thanks to Taproot, allows the creation of more complex contracts with multilateral signature and opens up the possibilities for creating decentralized autonomous organizations (DAOs) and other DeFi applications based on Bitcoin.
Impact of Taproot
As a soft fork, Taproot has the oppositecompatibility with old software versions and can check all old types of transactions, however, those users who want to check taproot transactions must update their software clients to the latest version of Bitcoin Core.
Since most wallet operatorswill continue to use ECDSA after activating Taproot due to its proliferation and standardization, all of Taproot's capabilities will not be revealed immediately. In addition, blocks will continue to contain both Schnorr-signed and ECDSA-signed transactions, limiting the ability to take advantage of batch validation in the short term. But over time, more widespread adoption of this technology will occur and most transactions will use Taproot, even if the user does not know about it. However, full adoption will not be realized overnight, and individual users are likely to start using Taproot before businesses and organizations.
Since Taproot was in development alreadyfor many years, some market participants have argued that its influence is already fully reflected in the price of BTC. Others still expect Taproot activation to trigger a strong surge in the market, albeit with some lag from the activation date. In fact, it is most likely that other factors will affect the price in the short to medium term, and that Taproot will not have a significant impact on the price in the coming years.
But regardless of short-term fluctuationsexchange rate, such a technology update significantly increases the attractiveness of Bitcoin for creating on its basis DeFi-protocols, which may attract additional demand for a limited resource of digital coins available for purchase. In particular, key aggregation allows Bitcoin to compete with higher bandwidth blockchains such as Ethereum, which is the main hosting platform for DeFi projects today. Ultimately, Taproot potentially opens the door to new Bitcoin-based DeFi networks (sidechains) - such as Sovryn, Thorchain, or Portal - by opening multilateral (e.g. 1000+ participants) signed vault contracts that block bitcoins from being used. on the sidechain and cost as a standard one-way signed transaction. Prior to Taproot, implementing such sidechains with so many signers would have been prohibitively expensive.
Since large multisig smart contracts withhundreds or even thousands of signers before Taproot were too expensive, Bitcoin still hasn't generated much interest from DeFi protocols. Ethereum hosts over 64% of existing DeFi projects, while Bitcoin hosts around 7.5%, according to DeFi Prime.
In addition, segwit transactions and lightning channelswill become more widespread now that a much better option is available. However, this will not be easy to measure, since channel opening and closing transactions in the case of using Taproot will be indistinguishable from regular taproot transactions.
Finally, Taproot has the potential to createa strong market for miners' fees after the last bitcoin is mined around 2140. This theory suggests that if there is a significant demand for confidential transactions, users may want to passively participate in CoinJoin transactions, in which their wallet balances will be pooled into a single transaction with multiple senders, thus increasing the “anonymity pool”. If the adoption continues to grow, commissions for on-chain transactions may rise, which will help maintain demand for mining even after the last bitcoin is released. Either way, Taproot is killing two birds with one stone, making Bitcoin more viable as a store of value and as a medium of exchange (both of these use cases have been contested by critics due to scalability issues and highly volatile market prices).
Taproot is the flagship update for Bitcoin.optimizing network scalability, transaction confidentiality and expanding the functionality of smart contracts. Schnorr Signatures (BIP340) alter the underlying cryptography of Bitcoin by allowing the aggregation of keys and signatures, making multisignature transactions indistinguishable on the blockchain from standard one-way signed transactions. Taproot (BIP341), meanwhile, relies on the Schnorr schema to create an updated type of SegWit transactions with flow instructions based on Taproot, Schnorr signatures and MAST; this allows you to create more complex spending conditions and reduces the amount of information disclosed in the blockchain about these conditions. Finally, Tapscript (BIP342) allows the updated version of the Bitcoin scripting language to integrate the new spending terms that were made possible with the activation of Taproot, and makes it easier to implement future network updates. Tapscript not only integrates new technological solutions into Bitcoin, but also enhances the privacy and efficiency of existing solutions such as SegWit and Lightning Network. These new solutions have the potential to significantly increase network bandwidth and attract new users to Bitcoin, but realizing this potential may require a significant degree of adoption and user adoption.
Mass distribution of Bitcoin, stillis a controversial issue and not least depends on the quality of privacy guarantees and the ability to scale, which means that the need for better solutions for ensuring privacy and scalability will grow in the long term. And thanks to the technical solutions implemented in the Taproot soft fork, Bitcoin today is one step - or even several steps - closer to solving these critical problems.
This update is important because despitethe existence and willingness to implement many mature cryptographic privacy mechanisms typically involve significant trade-offs that most stakeholders cannot agree to. Taproot, on the other hand, has achieved near-perfect consensus as it does not involve any significant trade-offs. Together, Schnorr Signatures, Taproot and TapScript fundamentally empower users and, without exaggeration, open a new era in the development of Bitcoin.
BitNews disclaim responsibility for anyinvestment recommendations that may be contained in this article. All the opinions expressed express exclusively the personal opinions of the author and the respondents. Any actions related to investments and trading on crypto markets involve the risk of losing the invested funds. Based on the data provided, you make investment decisions in a balanced, responsible manner and at your own risk.