Prerequisite concept: MASTWhile many will associate "programmable money" with the Ethereum blockchain, the Bitcoin blockchain boasts its own, although somewhat less expansive, smart contract functionality. Bitcoin uses a simple programming language called Script which allows for conditions to be specified in order for funds to be unlocked, e.g. through a timelock script, a multi-sig, or several conditions.Put simply, Bitcoin transactions work by first locking Bitcoins in a script (or spending conditions), before unlocking and locking them again in new scripts. At present, if Alice sends Bob 1 BTC but wants to set multiple conditions for him to redeem them, then all conditions would be visible on the blockchain. In other words, transactions with multiple conditions may reveal information about the counterparties and reduce privacy. Furthermore, they could be a factor which biased miners use to avoid including the transaction in their blocks.MAST (Merkelized Alternative Script Trees) is a way to hide all spending conditions and reduce the size of the information. Instead of each condition being included in the transaction information, MAST produces a merkelized hash of the information (the merkle root). When Bitcoin is sent to a MAST output, the Bitcoin is locked to the Merkle root of these scripts, and to redeem the bitcoin the spender must reveal the script which they are using to unlock the Bitcoin, as well as proof that this script is included in the Merkle root of the previous transaction. The improvements in privacy and efficiency come from the fact that the spender of a MAST output does not have to reveal all the scripts, only the one they used. No one can see how many there are. No one can see what the others are.MAST has never been implemented in Bitcoin so far because the changes needed are extensive and complex. This is where the Schnorr/Taproot/Tapscript proposal comes in, as a middle ground between simplicity and added functionality.
Note: the abbreviation MAST originally stood for Merklized Abstract Syntax Trees based on merkle trees and abstract syntax trees. Subsequent proposals did not use abstract syntax trees but people continued to use the term “MAST”, leading Anthony Towns to propose the backronym Merklized Alternative Script Trees.
Schnorr SignaturesAt present, if one wants to sign a transaction with multiple signatures, each private key owner must compute their signature and include it in the transaction. BIP 340 introduces Schnorr signatures, which enables Bitcoin multi-sig transactions to appear as if they were single signature transactions (Pay-to-Public-Key-Hash, ‘P2PKH’ transactions) on the blockchain. In other words, the Schnorr signature scheme can hide that a MAST-structure existed at all; the transactions will be indistinguishable.This will allow signers to jointly produce a signature rather than having to compute them independently. As such, Taproot will increase privacy while reducing the amount of information and data space, thereby lowering transaction fees and improving scalability.
TapScriptTapScript is a new form of script that gives Bitcoin smart contracts more flexibility by removing the 10,000-byte size limit, giving developers more freedom to create Bitcoin smart contracts. Instead, script size is implicitly bounded by the block weight limit. It also enables partially executed scripts to have the rest of their execution code hidden until it is used. Consider the Merkle tree of Taproot, where every leaf is a script that is combined with a so-called leaf version—similar to script versioning with SegWit. The key difference is that the scripts are not revealed at time of payment, only at time of spending. Using a specialized Bitcoin script is easily identifiable to outside observers, but with Taproot, all outputs look the same. This enables a new type of payment called Pay-to-Taproot (P2TR), which means that users can pay to either a Schnorr public key or the Merkle root of other scripts. By validating these newer forms of transactions, TapScript provides users with a choice of being anonymous or remaining public.
Key AggregationSchnorr’s key aggregation feature is what enables this flexibility. The term key aggregation refers to multi-sigs that look like a single-key signature. When Bitcoin is sent to a P2TR output, it is locked to a single public key, called Q. However, this public key Q is really an aggregation of a public key P, and a public key formed from the Merkle root of many other script types. If the hash is valid, any of the alternative scripts in the Merkle tree can be used to spend the output. Multi-sig outputs, single-sig outputs, and other complex smart contracts will become indistinguishable; thus many on-chain analysis methods will become useless, protecting the privacy for all Taproot users.
To illustrate an example, consider closing a Lightning channel.The basic implementation of the current Lightning channels is based on a 2-of-2 multi-sig. Instead of closing a channel with a complex script, Schnorr allows signatures to be joined together, which are presented as one Taproot signature. This makes complex transactions more efficient, and to an observer, the channels would look like regular Bitcoin transactions.Since the Taproot upgrade will increase Lightning Network efficiency, it will also allow for increased development on Lightning.