Taproot - Sowing the Seeds for Bitcoin DeFi
Nov 10, 2021
Taproot – A peaceful revolution
Taproot (TR) is the first Bitcoin protocol soft fork since Segregated Witness (BIP-141) in 2017. SegWit provided a major step forward in that direction, sadly with a highly contentious soft fork including a long and fierce debate about both its substance (c.f. ”Blocksize Wars”) as well as the appropriate activation method. Taproot, on the other hand, is a rather peaceful revolution: over 90% of miners signaled support for the activation process – following the‘lock-in by block height’ (BIP 8) method– in June 2021, several months ago. In a few days, at block height #709632, Taproot will be activated on the Bitcoin network. SegWit’s legacy is that it helped enable Layer-2 innovations like Lightning, powerfully demonstrated the role users play in deciding upon Bitcoins’s future, and with that it paved the road for Taproot. Having laid the groundwork, Bitcoin developers expect Taproot to be a key enabler for more complex transaction spending conditions and “smart contracts” on the Bitcoin/Lightning network (LNP/BP), sowing the seeds for Bitcoin-native Decentralized Finance in the future.
Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main areas: efficiency and privacy. Efficiency because unexecuted forks of a script can avoid ever hitting the chain, and privacy because hiding unexecuted code leaves scripts indistinguishable to the extent that their only differences are in the unexecuted parts. (…) One point that comes up while talking about merkelized scripts is can we go about making fancier contract use cases as indistinguishable as possible from the most common and boring payments. (…) It turns out, however, that there is no need to make a trade-off. The special case of a top level "threshold-signature OR arbitrary-conditions" can be made indistinguishable from a normal one-party signature, with no overhead at all, with a special delegating CHECKSIG which I call Taproot.
Gregory Maxwell, announcing the Taproot idea on bitcoin-dev mailing list, 23 January 2018
Digging Deeper to get to (the) Taproot
Let us start with a quick review of the term: while “Taproot” itself is an umbrella term for the upcoming soft-fork, it actually consists of three separate Bitcoin Improvement Proposals (BIPs) – BIP340, BIP341 and BIP342. Confusingly enough, BIP341 is also referred to as “Taproot” on its own right.
Before diving deeper into each of those, we can already state that Taproot will enable more interesting sets of spending conditions, smart contracts if you will, to unlock bitcoins, in a more privacy-preserving way as even the most complex transactions will be indistinguishable from normal transactions until the spending condition is revealed. Already today, different types of locking scripts (timelocks, multisigs, etc.) can be combined to create complex Bitcoin transactions. Let’s say in an example transaction/contract, coins could be spent in three ways: (a) if Alice and Bob sign, (b) if Alice signs alone after waiting for a time period, and (c) if Bob signs alone while providing a secret number. While transactions of type Pay-to-script-hash (P2SH) hide such contract code behind a hash, spending the coins reveals the full contract code. As anyone can then see the entire contract logic, including all branches i. e. also paths not taken and parties not involved, this is both a privacy concern and a data burden as much more has to be stored on-chain than is actually needed to successfully execute the transaction. Even if privacy would not be a major concern, very complex transactions, for example multisig transactions with many private keys involved, are cumbersome to encode – a roadblock if one wants to implement logically non-trivial smart contracts on the Bitcoin network in the future.
Schnorr signatures (BIP 340)
Bitcoin assigns bitcoin amounts to public keys, which we call “unspent transaction outputs” (UTXO). A user makes a transaction by digitally signing the message “send coins on public key/address A to public key/address B” with their private key. (Therefore, losing private keys means losing access to coins and keeping private keys safe is of utmost importance.) Up until now, Bitcoin only uses the ECDSA algorithm to generate and verify signatures and is about to introduce a new construction – Schnorr. What are the benefits? First, the Schnorr algorithm allows so-called signature aggregation. The multiple keys for a multisig transaction can be aggregated into a single signature “containing” all individual signatures. This not only reduces the size of multisig payments, but also increases the overall privacy because Schnorr signatures make Lightning channel transactions, multisigs, and normal transactions all look alike from an outside observer’s perspective. In addition, Schnorr signatures themselves are 11% smaller than ECDSA signatures, reducing fees for all transaction types.
Taproot/SegWit v1 spending rules (BIP 341)
Taproot (TR) will expand Bitcoin’s smart contract flexibility and offer more privacy in doing so by proposing a new transaction output type, called SegWit version 1 (BIP-341). TR transactions will allow for two different ways of spending an output, a default keyspend and an arbitrary alternative spending path called scriptspend. The latter spending paths are implemented using Merkelized Abstract Syntax Trees (MAST). MASTs (BIP-116, 117) allow to represent spending paths of complex conditions in a decision tree structure consisting of spending branches. While previously the entire unlocking script is revealed in the process of spending, a TR transaction only reveals the actual spending path taken and hides however else these coins might have been spent, thus increasing the level of privacy, especially in multi-party contracts.
Tapscript (BIP 342)
To validate Taproot scripts the Bitcoin Script language in its current version needs to be extended on the level of accepted opcodes, the commands or functions used to construct transactions. While it would be beyond the scope of this article to dig deeper into technical details, it suffices to say that some opcodes are needed to accommodate Schnorr signatures. Hence some aremodified and others newly introduced. Two ramifications are noteworthy for users; First, Tapscript allows to describe transaction scripts using MAST trees and thus enables much more complex, contract-like control over spending Bitcoins. While this is a step towards “smart contract” functionality, acrucial difference between scripting in Bitcoin and Solidity contracts in Ethereum remains: Bitcoin stays non Turing-complete to keep the complexity of programs low and make them less prone to bugs and unintended side effects. Second, Tapscript introduces a versioning system for spending rules and constitutes v1 of these rules; v0 was implemented by SegWit (BIP 143) some years ago. The benefit is that enhancing the scripting language in the future will be significantly easier as it can be done by backward-compatible soft forks instead of more disruptive hard forks.
Over the years and in light of other cryptocurrency projects, Bitcoin had to face criticism in many different areas: it does not scale, it is too slow, it is too transparent, and it cannot do smart contracts. Abstracting the technical details mentioned above, one can say that the Taproot upgrade moves Bitcoin forward in three distinct and crucial areas that together address all of these criticisms: scalability, privacy and fungibility, and functionality. The following table provides a non-technical overview.
Table 1. Taproot improving Bitcoin across three crucial domains of criticism in the past.
- Smaller multi-sig transactions because of signature aggregation (30-75%)
- Batch validation, 2.5x faster block validation
- General fee savings because of compact transaction size
Privacy & Fungibility
- All outputs and most spends are indistinguishable from normal transactions
- Most script evaluation can happen off-chain
- Spending only reveals the fulfilled path, not the entire script
- Large M-of-N multisig transactions possible
- Larger general scripts possible
- Script innovations (adapter, blind signatures, etc.) enabling complex DeFi and LN improvements
Although Taproot is a deeply technical upgrade seated in the machine room of the Bitcoin protocol, its impact could turn out to be profound. After SegWit enabled lightning-fast payments, Taproot may enable complex smart contracts and unprecedented on-chain privacy. These are crucial building blocks that will ultimately make higher layer constructs like Decentralized Finance and Non-Fungible Tokens a possibility. DeFi and NFTs proved to be a booster for developer interest and user traction already once: the first DeFi wave happened on the premier smart contract platform, Ethereum and the price of its native token ETH reflects that. Maybe Bitcoin will not yet be ready and the second wave of DeFi will happen on Ethereum competitors’ platforms. But then again, patience also proved fruitful during the SegWit adoption phase. For the third wave, Bitcoin may offer an attractive platform with foundational reliability for smart contract developers that offers the largest network, the highest security, significantly higher privacy, and a most attractive price development – with comparably low fees. Let’s see what orange fruits will grow from the taproots…