Bitcoin developers are constantly looking for ways to improve the Bitcoin scripting language with three interrelated goals in mind: improving privacy, optimizing space efficiency (the space data takes up on the blockchain), and increasing computational efficiency (the effort nodes use to verify transactions). Developers want all operations, from simple spends to complex set ups, to be as private as possible, leave as small of a data footprint as possible, and be as easy for others to verify as possible.
Taproot is a proposal made by Greg Maxwell that is very much in line with these intentions. Maxwell proposed Taproot in early 2018 in order to address the privacy and scaling issues that complex smart contracts pose to Bitcoin. Complex contracts are currently data heavy, take time to fully verify, and can leak a lot of unnecessary information about the transaction.
The goal of implementing Taproot in Bitcoin, is to make complex scripts look and feel like ordinary transactions, reducing the data load and improving the privacy of users taking advantage of Bitcoin’s full capabilities.
Units of Bitcoin are locked in what are called “scripts”. These scripts are instructions or conditions that need to be met in order to spend certain units of Bitcoin. Most Bitcoin is locked in simple scripts that require a user to provide the appropriate digital signature that corresponds to the appropriate public key. Once a user has proven possession of the correct private key via a digital signature, the units of Bitcoin are free to be spent to any other valid address. This is your standard, run of the mill transaction.
However, there are other scripts that can be used that are more complicated. These more complex scripts, with more conditions, are typically referred to as “smart contracts”. The common examples given for Bitcoin smart contracts are multi-signature set ups, time-locks, or multi-signature set ups with time-locks.
Under the current paradigm, any time someone or some group spends Bitcioin, the entire script is revealed to the network and recorded forever. Even the parts of the script that were just possibilities but never came to fruition are revealed for any on-looker to see. This isn’t ideal for privacy since everything about the transaction is revealed, even outcomes that didn’t actually happen. Not only does this compromise privacy, but it’s also an inefficient use of blockchain space and an inefficient use of network computation.
In the current state of Bitcoin, all of the conditions of a smart contract are included in a single hash. This means when any of the data is revealed in that single hash, all of the data is revealed to the network. To solve the problem of revealing unused portions of a script, the Taproot proposal has all of the conditions in the script hashed individually and then synthesized into a single hash known as a Merkle root. This means that only the conditions that are met are revealed and the other conditions that did not come to fruition remain hashed and thus private.
The technical name for this organization of hashed scripts is known as a Merklized Abstract Syntax Tree (MAST). Although a MAST structure keeps these unused conditions private, an outside party still knows there were other conditions. To make it even more private, Taproot makes use of Schnorr signatures, which we wrote about in our last blog covering Bitcoin development.
To quickly summarize, Schnorr based cryptography is being proposed for use in Bitcoin because it’s more flexible than the current ECDSA cryptography being used in Bitcoin. This flexibility helps Bitcoin become more scalable and private, especially when used in multi-signature set ups. Please check out our previous blog to learn more about Schnorr.
Leveraging the aggregation property of Schnorr, Taproot is able to make the very existence of a MAST structure non-existent to any snooping onlookers. Aggregation in this context refers to Schnorr’s ability to combine multiple digital signatures into one “aggregate” signature. A 15 of 15 multi-signature set-up would normally require the revelation of 15 public keys and 15 signatures in order for the Bitcoin network to verify the transaction. With Schnorr, this set of 15 can be aggregated into one aggregate public key and the outputs (units of BTC) associated with that public key can be spent using only one aggregate signature. Using Schnorr a transaction coming from a 15 of 15 multi-signature set up will look like a regular transaction.
No matter what the set up or the outcome of a complex smart contract, Taproot will make it look as though it was a standard 1 public key, 1 private key transaction with no other conditionals. This increases privacy for multi-party contracts and reduces the data load needed to be verified and maintained by nodes participating in the network. A win, win for privacy and scalability.
Criticisms and Concerns
Although Taproot has received a lot of developer and community support over the past two years, this past February a group of anonymous developers published some of their concerns about the proposal. The concerns are highly technical and their validity is above the pay grade of this author, but at a high level they revolve around the wisdom of combining the MAST & Schnorr technologies against deploying them separately.
The proponents of Taproot think the combination of MAST & Schnorr is an efficiency and privacy gain, but this other group of developers challenge the assumptions that make that efficiency and privacy possible. The critics are largely proponents of Taproot, but wanted to voice some of their concerns around some of the assumptions made and how it’s being deployed.
These critics are an example of the arduous process and attention to detail these proposals are subject to. After two years of development there are still objections made and clarifications wanted by members of the Bitcoin development community. This type of care and critical thinking is crucial to such an ambitious project, supporting a lot of present value and a lot of possible future value.
Oftentimes, when attempting to optimize and solve problems in a complex system like Bitcoin, unavoidable trade-offs emerge. You might be trying to improve one property of the network and your solution, although it works, makes some other property or other properties worse off. Taproot seems like one of those elegant engineering solutions that is able to avoid negative tradeoffs while yielding great benefits to the system as a whole.
It’s not clear when Taproot will be included in the next upgrade of the Bitcoin Core reference client. The vetting process of upgrades to Bitcoin is long and difficult. Developing technical and economic consensus in such a high value system is extremely tough. However, these proposals seem to have garnered enough support as of this writing to make it highly likely that much of the network will agree to the upgrade.