What are Taproot, MAST and Schnorr Signatures?
Although hitting the spotlight over the first few months of 2019, Taproot was first proposed by Gregory Maxwell back in January 2018 as a method of improving both the scalability and privacy of bitcoin transactions. It includes a number of components and seeks to address the trade-off between the blockchain being a public store of data and the privacy needs of users.
As such, it aims to improve the smart contract functionality of the bitcoin blockchain in order to allow transactions with complex conditions to appear as standard transactions. Let’s unpack this a little …
Bitcoin and Smart Contracts
Whilst many people will associate smart contracts with the Ethereum blockchain, the bitcoin blockchain also boasts its own, even if somewhat less expansive, smart contract functionality. Bitcoin uses a scripting language called Script which allows for conditions to be specified in order for funds to be unlocked — referred to as the redeem script. I discussed these in detail within a previous post (https://www.linkedin.com/pulse/understanding-bitcoin-transactions-tara-annison/) and the TL;DR is that this is a Pay-to-Script-Hash (P2SH) where conditions are set for redemption e.g through a timelock script, a multi-sig or a number of conditions.
However, at present, if one were to create P2SH redeem script, the conditions would be visible to all network participants once the funds are spent. This reduces privacy and is more data intensive, therefore affecting scalability. However, the aim of Taproot is to ensure that P2SH transactions appears indistinguishable from other transaction types therefore improving privacy and scalability. In order to achieve this, it will introduce two improvements: Schnorr signatures and Merklized Abstract Syntx Trees.
Schnorr Signatures
Signatures are created by the private key owner to prove ownership of the private key without revealing it. They are publicly verifiable using the public key and Bitcoin uses a signature scheme called ECDSA — Elliptical Curve Digital Signature Algorithm.
At present, if one wishes to sign a transaction with multiple signatures, each private key owner must compute their signature and include it within the transaction. This is data intensive for the transaction, requires the verifiers to verify each signature individually as there’s no signature verification batching within core, and reduces privacy since the number of and each signature is included within the transaction information.
The proposal within Taproot is replace EDCSA with Schnorr signatures and therefore allow signers to jointly produce a signature, rather than needing to compute independently and add to the transaction. This is an interactive and efficient process which obscures the number of original signers and any threshold conditions (e.g n of m signers are required to redeem), therefore improving scalability and privacy.
The second part of Taproot is the introduction of Merklized Abstract Syntax Trees.
Merklized Abstract Syntax Trees
MAST looks to provide additional privacy for complex redeem conditions by hashing the various potential routes.
At present, if Alice sends Bob 10BTC but wishes to set a number of conditions on him redeeming them, then all conditions would be visible on the blockchain.
Example Conditions:
a) Bob can spend the 10 BTC only if he waits 7 days
b) If he wants to spend them before 7 days elapse, he can only access 4 BTC and the remaining 6 should be returned to Alice at a specified address.
The above conditions make use of a timelock script which allows for either a block or time (in epoch format) to be specified within the transaction information. This field is usually set to ‘0’ and therefore a non-zero value reduces privacy in the transaction, increases the transaction size and could be a factor which biased miners use to avoid including the transaction in their candidate blocks.
https://medium.com/@RobinHung/bitcoin-timelocks-in-a-nutshell-4c95aafc7a59
In addition, transactions with multiple conditions will reveal further information about the counterparties intentions and reduce privacy.
Taproot aims to use MAST in order to hide all conditions for spending and reduce the size of this information. As such, instead of each condition being included in the transaction information, MAST produces a merklized hash of this information (the merkle root) thereby reducing the size of the information and hiding the various routes the transaction may take.
Jeremy Rubin: https://rubin.io/projects/MAST/
This allows for a commitment to all conditions without revealing each condition individually.
Furthermore, upon transaction execution MAST only reveals the successful route taken, and maintains the obscurity of the existence and details of alternative paths.
Taproot uses MAST to include the merklized hash as the public key, thereby then includes making a complex script transaction indistinguishable from a standard P2PKH transaction.
In our example above, let’s consider an additional condition:
a) Bob can access the 10 BTC before 7 days but only if Charlie also signs the transaction.
Using Taproot, the transaction would appear as any normal P2PKH transaction and upon Bob successfully receiving the 10BTC it would be possible to know that this was because he waited the 7 days, however it would not be possible to know that he could have accessed the funds earlier had Charlie also signed the transaction, since this alternative route would not have been revealed — nor option b).
As such, the introduction of MAST within Taproot improves both the scalability for complex redemption conditions as well as transaction privacy by obscuring the existence of alternative routes.
It is therefore clear that Taproot provides an exciting improvement for bitcoin, and will increase both scalability and privacy of transactions. BIP `bip-taproot` was submitted in early May (https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki) and it is hoped that it can be included as an uncontentious soft fork — especially since it was a driving factor for pressing forward with SegWit last year. There will now be a number of months for peer review and further technical discussions before the BIP is introduced on the bitcoin testnet and then, if all goes well, it should be included in a 2020 or 2021 update.
For more blockchain and cryptocurrency information, follow me on LinkedIn @TaraAnnison
