Much has been written about Bitcoin’s Taproot upgrade, and plenty of resources exist to explain its technical concepts. However, in the author’s opinion, a more comprehensive roundup of why Taproot is being implemented, what it will bring to the network, and what it might enable for the future, in plain English, is still lacking. Driven by the misconceptions that regular users have about Taproot and a certain lack of understanding, this essay leverages the technical resources that came before it to enlighten you to the broader implications of what is arguably the most significant upgrade to Bitcoin yet.
Why Taproot Matters
In short and at the highest level of abstraction possible, the Bitcoin Taproot soft fork will optimize scalability, privacy, and smart contract functionality. It will bring about a new address type, allowing bitcoin spending to look similar regardless of whether the sender is making a simple payment, a complex multi-signature transaction, or using the Lightning Network. Moreover, Taproot addresses will allow users to save on transaction fees — the more complex the spending conditions, the more the user will save — compared to previous address types. By reducing the transaction size and making nearly any transaction appear like a simple, single-signature one, Taproot will also enable larger and more complex operations to be deployed on Bitcoin that were previously unfeasible or almost impossible.
If you only use Bitcoin to hold coins long term and sparingly move them around between wallets, you might think Taproot will have little impact on you. But in fact, the possibilities that this soft fork will enable for Bitcoin’s future are extensive, as Taproot lays the groundwork for more prominent and more significant developments to land on the network.
For one, Taproot ultimately empowers the Lightning Network to unleash its full potential as a proper scaling technology for Bitcoin. Currently, the second layer protocol can be spotted in action in the Bitcoin blockchain, reducing coins’ fungibility. Fungibility is vital for a monetary good to actualize the medium of exchange role because it allows for coins to be seen as equal. If transaction outputs were seen differently, they could suffer from discrimination by the receiver, preventing users from using their BTC for payments in certain conditions.
In addition, the Lightning Network and other complex wallets and contracts will enjoy greater efficiency and lower transaction fees, further empowering the usage of Bitcoin as a medium of exchange. Enabled by Schnorr signatures, even the most complex transactions made between Taproot-supporting wallets will incur the same fees as simple ones. Furthermore, this reduction of costs and the increased flexibility and capabilities for smart contracts will ultimately enable very complex setups that were previously not feasible in Bitcoin.
But to comprehend why Taproot is being implemented in Bitcoin, one must first understand how Bitcoin transactions work and the many upgrades that have been made up to this point, naturally leading to Taproot.
A Quick Overview Of How Bitcoin Transactions Work
Bitcoin transactions work based on inputs and outputs, which are also equal since coins are not destroyed. If you want to send me 5 BTC, for instance, you would need to select precisely 5 bitcoin, else the transaction would be either incomplete, or you’d have too many funds.
For the former, Bitcoin can’t do much — you can’t send funds you don’t have — but for the latter, Bitcoin will give you the “rest” as change. Therefore, if you select 7.38 BTC to send me five, 2.38 will go back to you as change. So you’d have 7.38 as input and 2.38 + 5 as outputs, although you’d receive a little less than 2.38 because the network needs to deduct the transaction fees.
When we talk about spending, we are referring to an output. Now that I have the 5 BTC you sent me, I can use it as I wish. I can send 3 BTC to Alice and 2 BTC to Bob, for instance, or I can send 5 BTC to Joe. Or I can keep the 5 BTC and HODL indefinitely. Unless I choose to hold it, I will be making a transaction regardless of the use I make of my new bitcoin. This latest transaction will get the 5 BTC output I have as input, and this transaction’s output will be whatever I decide to send. Notice that since I received the 5 BTC in full, even if I want to send only 3 bitcoin, I will have to input all the 5 bitcoin into the transaction, and I’ll get the rest back as change.
What’s essential in this dynamic is to realize the interaction of coins as inputs and outputs. When we spend, we are transferring a transaction output to another person. But to do that, we need to input it into a new transaction, and the other person will get the BTC as another transaction output. For that reason, the concept of a wallet is an abstraction intended to make things easier to acknowledge and understand by summing up all the transaction outputs you own. Because after all, that’s all there is — transaction outputs (UTXOs).
Improving The Bitcoin Transaction Model
The history of paying in bitcoin has changed a lot since the early days of the network. Overall, the UTXO model described above relies on scripts or contracts created using the Bitcoin Script “programming” language. This author has put “programming” in quotation marks because Bitcoin’s scripting language can more accurately be seen as a verification language than one that provides computation directives. In essence, Bitcoin scripting is a way to specify conditions for spending a UTXO.
There are three major constraints when considering Bitcoin Script and how its improvements are made: privacy, space efficiency, and computational efficiency — usually, improving one of these cascades into strengthening the other two. For instance, seeking to reveal less about a transaction and thereby improving privacy would entail submitting a smaller amount of data, reducing space needs for the transaction, and making it easier to be verified — it’s less computationally intensive.
The community has been improving how Bitcoin transactions work by gradually introducing new script, or address, types. Ultimately, these changes have sought to enhance transactional privacy, make the transfer of funds more lightweight, and speed up the process of validating transactions. As a result, users have greater flexibility for creating scripts that increase the resilience of their savings, move funds around more efficiently and privately, and help unleash financial sovereignty. Albeit complicated for the end-user, technical tools have emerged to adopt these practices and abstract low-level technicalities, ensuring greater adoption of current best practices.
One clear example of this is multisignature addresses, which once had to be done manually with Bitcoin Script but can now be effortlessly created with a smartphone or a laptop. The same is true for Lightning, Bitcoin’s second-layer scaling solution for small and frequent payments. This Layer 2 is now available in mobile apps and allows for people to transact once-unfeasible amounts of BTC with each other instantly.
Taproot, the latest upgrade to the Bitcoin protocol and arguably the most important one to date, is a natural evolution of the way Bitcoin transactions, and hence scripts, work. Enabled by Schnorr signatures, MAST and Tapscript, Taproot seeks to increase flexibility and privacy without compromising security.
In the early days of Bitcoin, with legacy addresses, the sender of a transaction had to care about the receiver’s wallet policy — its contract, or script — which was not only impractical but represented a significant privacy shortcoming. The contract had to be revealed when the transaction was sent for anyone to see; hence, the receiver’s privacy was low.
With the advent of pay to script hash (P2SH), Bitcoin changed that dynamic, and transactions started to be sent to the hash of the contract instead of the contract itself. This meant the contract wouldn’t be revealed until the output was spent, and outputs became identical — just a hash.
A hash is the output of a hashing function, which takes a variable-length input and returns an encrypted result of fixed length. Not only did this addition to Bitcoin transactions improve privacy by making all outputs look similar, but it also reduced the output size, thereby increasing efficiency.
However, the contract had to become visible when spending and all of the spending conditions had to be revealed. The two downsides with this approach are privacy and efficiency, as any observer could learn about the different spending conditions — thus learning plenty of information about the spender — and the blockchain would be bloated with a large script with unnecessary logic — it only makes practical sense to verify the spending condition that was used to spend that output.
The Taproot upgrade improves this logic by introducing Merklelized Abstract Syntax Trees (MAST), a structure that ultimately allows Bitcoin to achieve the goal of only revealing the contract’s specific spending condition that was used.
There are two main possibilities for complex Taproot spending: a consensual, mutually-agreed condition; or a fallback, specific condition. For instance, if a multisignature address owned by multiple people wants to spend some funds programmatically, they could set up one spending condition in which all of them agree to spend the funds or fallback states in case they can’t reach a consensus.
If the condition everyone agrees on is used, Taproot allows it to be turned into a single signature. Therefore, the Bitcoin network wouldn’t even know there was a contract being used in the first place, significantly increasing the privacy of all of the owners of the multisignature address.
However, if a mutual consensus isn’t reached and one party spends the funds using any of the fallback methods, Taproot only reveals that specific method. As the introduction of…