In the medium term, the Bitcoin protocol can support Taproot technology, which focuses on increased flexibility of smart contracts while maintaining a fairly high level of privacy. It is assumed that users will not be able to distinguish simple transactions even from the most complex smart contracts.
Initially, Taproot was designed by Bitcoin Core developer and Blockstream's former CTO Gregory Maxwell. Currently, leading representatives of the developer community in the person of Peter Velle, Anthony Townes, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Raffing and Rusty Russell are working on implementing the Schnorr signatures, which includes Taproot technology.
BlockchainJournal offers you an adapted translation of an article by Aaron van Virduma published in Bitcoin Magazine about how Taproot works and why this decision will make Bitcoin stronger.
P2SH
All existing bitcoins are locked in scripts; these are a few lines of code in a transaction, defining how coins can be spent in the next transaction. A prerequisite for spending is a signature confirming the ownership of the coins. Nevertheless, one should not forget about the existence of timestamps [waste only after generating a certain block] and multi-signatures [waste only if authorized by a sufficient number of private keys].
To create complex smart contracts, you can combine various spending conditions. For example, coins can be spent if and only if Bob and Alice sign a transaction, or Alice signs it at the end of the week, or if Bob does so by giving a secret number. So, the condition that first activates a transaction determines how coins can be spent.
Since 2012, only the new Bitcoin holder knows how to spend it, and outside observers are not aware of the conditions of spending until its implementation. This became possible due to the implementation of the P2SH [pay to script hash] solution, which assumes that only hashes of scripts are included in the blockchain. This seemingly random number determines the ownership of the coins. At the time of waste holder opens the script and the key to decrypt the hash at the same time. Then each user can use the original hash to check the truth of the script and fulfill the conditions of the waste.
However, users must disclose all conditions of spending, including those that were not met. There are two major drawbacks to this approach: a lot of data to process and a blow to privacy. If each user gets access to information about how the funds could be spent, he will theoretically be able to calculate the used wallet and other data.
MAST
A potential solution to these shortcomings was an abstract syntax tree based on the Merkle tree [or MAST ] for more efficient processing of data arrays. MAST involves the generation of individual hashes for each condition of spending coins and their subsequent inclusion into the Merkle tree, which produces a single hash or the so-called Merkle root. Last and "locks" the coins.
The elegance of the solution lies in the fact that the Merkle root and additional data in the form of Merkle branches can confirm the truth of certain data in the tree, without revealing the others. MAST only requires disclosure of the condition that activated the transaction, which makes the solution effective in terms of data processing, as well as in the context of privacy.
However, Taproot, in combination with the signatures of Schnorr, can completely hide the fact that such an abstract syntax tree exists.
Signatures Schnorr
At the moment, Bitcoin developers are working on the implementation of Schnorr signatures in the form of soft forks. Many cryptographers consider this scheme the best of the existing ones, since its mathematical properties provide a high level of correctness of calculations, it is resistant to plasticity and relatively fast in terms of confirming transactions.
The implementation of Schnorr signatures in the Bitcoin protocol will allow to aggregate several signatures for a single transaction into a single one at the expense of linear mathematics embedded in the scheme. The same approach can be applied to transactions with a multi-signature: by combining public keys and signatures into “threshold public keys” or “threshold signatures”, such transfers can be made indistinguishable from regular ones.
It is noteworthy that the Schnorr scheme allows you to modify public and private keys. For example, both public and private keys can be multiplied by 2, but they will still match each other and can be used to sign transactions. At the same time, other users will not be able to distinguish modified keys from ordinary ones, without knowing for certain that they have been changed. That is what will enable Taproot.
Taproot
Taproot is based on the following statement: any MAST construction, regardless of the level of complexity, must include a condition that allows all participants to agree on the result and sign the transaction together. If Bob knows that Alice will still have access to the funds next week, he can work with her together to sign the transaction together.
Thus, Taproot resembles MAST in its structure, but always presupposes the existence of a condition allowing all participants to work together for spending: the so-called “joint closure”. As soon as the signatures of Schnorr come into play, the concept becomes much more interesting.
"Joint closure" involves the ability to modify the keys so that the transaction seemed normal. Merging public keys and signatures of participants into single “threshold versions” will allow them to realize a waste. But in this case, they have only one option available.
Signatures Schnorr allow you to turn other conditions that do not involve "joint closure" in a separate script. This script passes hashing and is used to modify the “threshold public key” by multiplying. Clicking a similar procedure with a "threshold signature", you can get another pair.
Thus, if the “joint closure” has passed, then the “threshold signature” multiplied by the script allows participants to carry out the waste. At the same time, outsiders will still see a normal transaction.
If the “joint closure” turned out to be impossible, then you can reveal the fact that the “threshold public key” is a modified version of the true public key.
In this case, both the “threshold public key” and the script are revealed: this confirms the truth of the modified version and indicates that the waste could be realized provided that the alternative conditions contained in the script were observed.
This development implies the merging of the “threshold public key” with the Merkle root, since the Merkle tree contains all possible spending conditions. In this case, only the condition that was met is revealed.
Thus, Taproot offers all the advantages of MAST structures, but under normal circumstances no one will know that a simple smart contract was hidden behind a simple transaction.
Graftroot
Taproot is effective in the case of "joint closure", however, alternative options involve the disclosure of Merkle branches, which also entails the processing of large data arrays.
The Graftroot technology, proposed by the same indefatigable Maxwell, assumes that the participants of the smart contract create a “threshold public key”, but in the future they do not modify it. Instead, they sign scripts (alternative spending conditions) in order to create “threshold signatures” for each of them.
So, the user selects a specific script, stores it along with the corresponding signature, which can confirm that the alternative spending condition is true and approved by all participants [delegated].
Let us return to the situation with Bob and Alice, who can spend money under certain conditions. They have the option of “joint closure,” that is, Alice can spend the coins in a week, or Bob can do it if he uses the secret number. In this case, Bob and Alice combine public keys and create a “threshold public key” that allows them to spend money if they have a “threshold signature”. The latter will create with the direct expenditure.
Then Bob and Alice create and sign alternative scripts. Alice retains a “threshold signature” for a script that allows her to spend a week's time, and Bob does the same for a secret number script. Note, however, that “threshold signatures” and corresponding scenarios for spending are not enough: they only serve as confirmation that Bob and Alice agreed on conditions. For the implementation of waste, you must fulfill the conditions laid down in the script.
In the event of a “joint closure” failure, participants must disclose an alternative script and “threshold signature”. Third-party users will be able to match the “threshold public key” with the “threshold signature” to confirm that the conditions in the script have been approved by all parties. In this way, both Bob and Alice can spend money, and other users will never know about the availability of alternative scenarios.
The problem with the Graftroot solution is its interactivity. Participants must contact each other to confirm alternative scripts before spending. In addition, they must keep “threshold signatures” for each of these scripts, and if they are lost, they will be deprived of spare options for spending in the event of a “joint closure” failure.
Probably, the signatures of Shnorr and Taproot will be activated as part of a single upgrade, and Graftroot will be the next step. At the same time, Segregated Witness allows you to do this in the form of a softforka due to the “version control of scripts” function.
It is noteworthy that Graftroot hides the existence of alternative versions, but in each transaction the version of the protocol used should be indicated, which can show the users which technology was used. This is the main argument in favor of a comprehensive protocol update that immediately implements a package of changes.
Subscribe to the BlockchainJournal news in Telegram: BlockchainJournal Live – the entire news feed, BlockchainJournal – the most important news and polls.
BlockchainJournal.news
BlockchainJournal.news
