In recent years, several improvements have been made to the Bitcoin protocol. Among those expected to be implemented in the future, there are also MAST and Schnorr signatures. These will be followed by Confidential Transactions using BulletProofs, which are already active on monero and Taproot.
The Taproot protocol, proposed by Gregory Maxwell, allows expanding the functionality and flexibility of smart contracts (called scripts) on the bitcoin blockchain. Not only that, but Taproot also allows improving the privacy of users and in general of all transactions, since the protocol makes it possible to make even the most complex smart contracts indistinguishable from common transactions on the network.
This is an evolution and possible implementation of the MAST protocol.
Taproot: the evolution of MAST
What is MAST? And what is the current problem with bitcoin scripts? On the bitcoin blockchain, it is possible to run scripts created by users for spending bitcoin according to certain constraints. However, scripts are still rather limited compared to classic smart contracts.
In fact, when a complex script is created (with many constraints) on Bitcoin it is necessary that all the data and constraints of the script are inserted on the blockchain, both the parts used (a certain spending condition for example) and all those not used, as well as the related public keys, addresses, etc. All this unused data increases the size of the transactions.
Not only that, but they also reduce privacy by publicly disclosing more information than necessary. In addition, they limit smart contracts based on their size rather than transaction validation costs.
The MAST protocol allows the creation of complex smart contracts on BTC’s blockchain using Abstract Syntax Tree and Merkle Trees.
ASTs allow splitting a complex script into its individual parts, while Merkle Trees allow verifying that the individual parts belong to a complete script without the need for the entire code, which thus should not be included in its entirety on bitcoin blocks.
Using this approach, therefore, it is possible to create complex scripts and optimise the use of memory on the blockchain, as only the constraints of the script that are actually used are published on the bitcoin blockchain, leaving everything else out. This indirectly also has privacy advantages. The reason is quite simple: only essential data is entered in the blockchain. But there’s more that can be done, and this is where Taproot comes in.
Taproot needs Schnorr
Taproot is a particular implementation of the MAST protocol combined with the Schnorr signatures. For this reason, Taproot requires Schnorr signatures to work properly.
Schnorr aims to optimise the space occupied by signatures in the blocks. This also affects privacy. In fact, through Schnorr, it is possible to compress the signatures of all participants into a single signature. For multi-signatures involving several participants, it is possible to aggregate public keys and signatures into a single public key (Threshold Public Key) and signature (Threshold Signature).
It is indistinguishable from a classic public key. This makes it impossible to determine whether the spending of a given bitcoin has been authorised by a single person or by several persons. This new mode may allow multiple signatories to merge their signatures into one. This results in significant space savings and increased confidentiality.
But there’s more. Schnorr signatures can be used in an even more interesting way. It is possible to tweak both a private key and the corresponding public key. For example, a private key and its public key could be multiplied by two.
Although both are multiplied by two, they would continue to correspond. Then the tweaked private key could be used to sign messages that can be verified by the tweaked public key in the same way.
Obviously only those directly involved in the operation are aware of the tweak, thus making the public key appear indifferent to the others.
Since Schnorr is currently not active on Bitcoin, it is very likely that Taproot and Schnorr will debut together on the bitcoin blockchain in a future fork. To date, it is not known when this will happen.
The idea behind Taproot is based on a need for bitcoin scripts. Any script must, in fact, include a particular condition that allows all participants involved in a contract to agree in a common way on the outcome of the script and thus spend their funds: the “cooperative close“.
The cooperative close uses Schnorr to appear as a common transaction between two parties. All the public keys of the participants in the script are added together, creating the Threshold Public Key. The same thing happens with signatures, which create the Threshold Signature, which can actually make the participants of the script spend their bitcoin by closing the contract.
At this point, all the other conditions in which bitcoins can be spent come into play: the non-cooperative close. All these alternative conditions/constraints to close cooperatives are present in the script. The hash of this script is therefore used to perform the tweaking operation of the keys mentioned above. However, instead of multiplying the public key by a random number, the Threshold Public Key is multiplied by the hash of the script. Obviously, this public key corresponds to the relative Threshold Signature tweaked in the same way.
So, if the bitcoins of the script are spent cooperatively, all participants join their signatures to get the Threshold Signature to be tweaked with the script. This will then allow them to spend the money. On the outside (on-chain) all this will appear as a regular transaction with a public key and classic signature.
If instead a non-cooperative close is performed, meaning one of the possible other conditions in the script, the tweaked Threshold Public Key will be shown. In this case, both the original Threshold Public Key and the script are revealed in order to demonstrate that the tweaked Threshold Public Key was obtained with that specific script. The tweak mechanism, therefore, serves to demonstrate to the world that the funds of the script can be spent if the conditions – specified in the script – are met.
Applying all these concepts to MAST, instead of using script hashes to tweak the Threshold Public Keys, you can use the root of the Merkle tree that includes all the different conditions in which funds can be spent. In this way, to spend funds, only the condition met must be revealed, improving privacy and optimising the use of on-chain resources.
And that’s the potential of Taproot: it combines the flexibility of MAST for scripts with the privacy of Schnorr.