“Taproot” is major upgrade for Bitcoin that brings scalability, privacy, and composability enhancements and activated on the Bitcoin network at block height 709,632, which was mined early Sunday morning, November 14, 2021. This is the first upgrade to Bitcoin since Summer 2017.
Bitcoin upgraded for the first time since 2017 by activating Taproot, a set of upgrades that contain significant enhancements for scalability, privacy, and composability.
The upgrade process was extremely smooth in Bitcoin terms, perhaps paving the way for more upgrades in the future.
The upgrade contains significant improvements to some of Bitcoin’s foundational cryptography, but its benefits are unlikely to be realized or noticed by any but the most sophisticated Bitcoin users for some time, as wallet software must build tools to enable its use by average users.
Bitcoin development is extremely conservative and deliberate, and thus major upgrades are rare. And the process by which upgrades are added to Bitcoin has been incredibly divisive in the past. Even when there is broad agreement on an upgrade, as there is with Taproot, deciding how to activate it brings its own challenges. In this report, we explain some of the benefits of Taproot and examine the process by which Bitcoin is upgraded.
A major design goal for Bitcoin developers is to allow users to interact with the blockchain in the most minimalist way possible. Upgrades should add features while making transactions more compact, blocks easier to propagate, nodes easier to sync, and so on. More compact means more decentralized, or easier to decentralize. Other major goals include adding more composability (flexible programming options) and privacy features, though it’s currently unlikely that the community would support upgrades that enact these at the expense of compactness and decentralization.
What is Taproot?
The “Taproot” update is a rare upgrade that achieves all three of these design goals. Officially, Taproot is the name of a piece of the upgrade, but its catchy name has come to represent the entire bundle in popular discussion. First proposed by Greg Maxwell in 2018, the upgrade contains three Bitcoin Improvement Proposals (BIPs) written by Pieter Wuille, Tim Ruffing, A.J. Townes and Jonas Nick, and were merged into Bitcoin Core in October 2020 and released in Bitcoin Core 0.21.1 early this year. That didn’t enact the upgrade, though, but merely propagated the code out to nodes in preparation for the upgrade.
Bitcoin’s latest upgrade brings improvements to bitcoin scaling, all the while enhancing user privacy and adding new programmability features. Simply, Taproot:
Overhauls Bitcoin’s core cryptography, replacing ECDSA with Schnorr Signatures for Bitcoin’s signature algorithm. Satoshi used the Elliptic Curve Digital Signature Algorithm (ECDSA) in Bitcoin because it offers strong security guarantees with a low number of bits, and therefore size. ECDSA is based on elliptic curve cryptography (ECC). As Galaxy Digital’s Rachel Rybarczyk wrote, “the security of ECC, specifically the assumption that the Elliptic Curve Discrete Logarithm Problem is hard to solve, is why a bitcoin can only be spent by the holder of the private key and by no one else, allowing for the Bitcoin network to determine whether someone has ownership of some bitcoins and can spend them.”
Schnorr Signatures have the same cryptographic assumptions as ECDSA—meaning, they’re just as secure—but they have some interesting properties. First, Schnorr Signatures are linear, which allows for signature aggregation, meaning that multiple signatures can be combined into one signature. This has the potential to reduce the transaction size of more complex transactions.
In the future, we may see cross-input signature aggregation (CiSA) added as a feature, which would allow signatures from multiple inputs to be combined. This would allow for transactions in a block signed with Schnorr signatures to be combined, dramatically increasing Bitcoin’s “transaction throughput.” This has major implications for scalability, although the specifications for CiSA have not been finalized.
Ultimately, Schnorr Signatures are dramatically better than ECDSA, but at the time Satoshi invented Bitcoin, Schnorr Signatures were under patent and not available to the wider cryptography community either for research or use. Today, Schnorr’s patent has expired, and years of research by cryptographers confirm its safety and efficacy.
Taproot encompasses several features relating to Bitcoin’s transaction scripting. Taproot adds two new output (payment) types to Bitcoin called key path spending and pay-to-taproot (P2TR). Using Schnorr Signatures, Taproot allows complicated transactions to look like simple single scripts if the parties involved can agree on an outcome. For example, multi-signature scripts, Lightning Channel closures, atomic swaps, and other smart contracts would all look like a standard transaction to an outsider in the optimistic case. Taproot also adds new types of spending conditions to allow for even more complex and advanced programmability.
Implications of the Taproot upgrade
Increased scalability. Bitcoin transactions are sized by weight (or virtual bytes), a metric that conveys how hard it is for nodes to process the transaction. Users pay fees based on the number of “satoshis per virtual byte” they are willing to pay for the network to store and settle their transaction. The fees charged by miners are primarily based on the data footprint of the transaction rather than the amount of money transferred.
Any upgrade that allows you to convey more information with more compactly, using fewer bytes, is beneficial to users both individually and collectively. SegWit, added to Bitcoin in summer 2017 at the culmination of the “block size wars,” was one such upgrade that allowed for scaling via more compact transactions. Using Schnorr signatures and P2TR transactions, Bitcoin users will be able to pack even more information into even smaller transactions. In particular, the upgrade will allow Bitcoin’s most complex transactions—such as those used by exchanges, custodians, and Lightning Network users—to see the most size reduction. The space-saving from this upgrade applies to the bulkiest of transactions, which should dramatically free up block space and therefore allow for significantly more transactions per block.
Increased privacy. The combination of Schnorr and Taproot allows for any complex transaction to be indistinguishable from any other transaction if the parties involved can agree on an outcome. Specifically, multisig transactions, like those used for escrow, custody, Lightning Network initiations, and others, will be indistinguishable from simple transactions. Furthermore, with Merklized Abstract Syntax Trees (MAST), complex transactions with multiple spending conditions or signature schemes will become much more private, as users need only reveal the spending conditions used to the blockchain. Currently, transactors must reveal all spending conditions at the point of spending, which reveals more information than necessary to the blockchain. Now, users can reveal only those conditions used to spend, keeping the rest secret. The increased privacy will make it more difficult for observers to trace the spending history of bitcoin and attribute ownership of bitcoin on the blockchain, significantly improving bitcoin’s fungibility.
The upgrade makes cross-input signature aggregation possible, which is a future enhancement that could further collapse the amount of information stored on the blockchain. One major privacy tactic available to bitcoin users today, CoinJoin, could see major benefits from cross-input signature aggregation, specifically making CoinJoins significantly less expensive. CiSA is still theoretical, with no improvement proposal yet put forth to accomplish it. For background, tracking bitcoin ownership today relies on an important heuristic: assume that all inputs in a transaction (pieces of bitcoin used to send bitcoin) belong to the same user. CoinJoins are a type of transaction where multiple users provide inputs to a transaction and pay themselves back with equally sized outputs, making it difficult for observers to use this heuristic because the inputs are owned by different users. Aggregating signatures on the inputs to a CoinJoin transaction would make such transactions much less expensive, thereby supporting increased usage.
Increased programmability. Taproot also adds new opcodes (smart-contracting operations) that allow for more complex spending conditions. Contrary to popular belief, bitcoin does have “smart contracts.” The difference is that, unlike on Ethereum, Bitcoin transactions are not “blockchain aware,” meaning that they cannot run in perpetuity and be triggered by other state changes on the blockchain (other events that occur on the blockchain). Instead, Bitcoin “smart contracts” are transactions with complex spending conditions. Once executed, these “smart contracts” are complete. For example, you might say “this bitcoin can only be spent after X blocks,” or “this bitcoin can only be spent if 3 of 5 valid signatures collaborate to sign and spend it,” or “only a portion of the bitcoin can be spend after X blocks if 3 of 5 signers sign, but if only 2 of 5 sign, then this other portion can be spent, but only after X blocks,” and so on. These types of schemes are what make secure cold storage possible natively on-chain, enabling things like escrow, second layer solutions like the Lightning Network, and more. Taproot adds a few other parameters that can be used in these schemes. But even more broadly, the scalability benefits of the upgrade will make much more complex contracts less costly, removing some cost disincentives from contract deployers.
Types of Forks
Before explaining how upgrades are enacted, it’s important to give a brief background on forks.
Split in consensus. A split in consensus occurs when competing miners discover a new block at the same time, essentially creating two split chains with each suggesting a different path forward for the blockchain. This type of fork is only temporary – whichever version of the chain has the next block added to it will become the longest chain and therefore will be accepted by nodes as the “truth,” with the shorter chain being discarded by the network.
Changes in Protocol Rules
Unlike splits in consensus, intentional and conscious changes made to the underlying source code can create permanent forks.
Hard forks. Hard forks are non-backwards-compatible upgrades that will kick users who don’t upgrade off the network. Ethereum uses hard forks regularly to perform upgrades, requiring that all users, including businesses like exchanges, upgrade at a precise moment or risk being kicked off the network. This has caused major issues several times, including most recently when about 20% of the Ethereum network failed to upgrade correctly, causing significant outages across services on the network. (Ultimately, the affected services upgraded, and service returned to normal).
Benign hard forks, like those conducted on Ethereum, run the risk of actually forking the network, resulting in two separate coins. But hard forks can also specifically be used to create new coins in the case of disagreement; for example, Bitcoin Cash was created by hard forking Bitcoin in August 2017. Technically speaking, hard forks expand the rules of the network, creating new conditions outside the existing ruleset, making it impossible for older nodes to recognize new blocks as valid.
Soft forks. Soft forks are backwards compatible upgrades, meaning that users can choose to do nothing and still remain safely operating on the network. A good example of a soft fork is Bitcoin’s SegWit upgrade, which activated in August 2017. SegWit fixed a transaction issue that prevented the creation of the Lightning Network, while adding scalability benefits for all users who choose to send their transactions using a new format. However, the SegWit upgrade doesn’t require you to send your transactions in the new format—you can continue using old formats with no disruption, you simply fail to make use of the scalability benefits of the new format. Similarly, if you run a Bitcoin node and you don’t upgrade to newer Bitcoin software that is upgraded for SegWit, you can continue to validate that the chain is accurate, even that SegWit transactions are valid despite “not knowing what they are.” Technically speaking, soft forks add features by contracting the rules of the network, creating new conditions that are more limited than the existing ruleset, and therefore “fit inside” the existing rules. Taproot was one such soft fork – meaning it is backwards compatible – similar to the 2017 SegWit upgrade.
There is no standard activation method for upgrading Bitcoin, which is both a feature and a flaw. Bitcoin development is decentralized, and in any case, Bitcoin developers don’t control the software that nodes and miners choose to run. Getting everyone on the same page about an upgrade is a little like herding cats. To add features to Bitcoin, developers produce code and nodes and miners choose to run it. Ultimately, for new features to be enacted, a majority of the network must support those features. If there isn’t broad active agreement on the upgrade, it is unlikely to be enacted.
Bitcoin is governed by a triumvirate comprised of three distinct factions: developers, nodes, and miners. Notably, Bitcoin is the only blockchain network where nodes, a.k.a. users, have actively asserted their governance powers in this triumvirate, successfully thwarting a block size increase in 2017 despite heavy support from miners (and businesses in the space) by threatening to use a tactic known as a user activated soft fork. Ultimately, each faction has checks and balances they can wield over the others.
Given these competing factions and the control they share over the network, how to actually activate an upgrade is a complicated question. Luckily, the Taproot upgrade enjoyed broad support across each competing faction. Developers, users, and miners agreed that it was a positive upgrade for the network. Indeed, while miners were the primary source of demands for block size increases and actively opposed the implementation of SegWit in 2017, a super majority of miner hashrate signaled support for Taproot. There is no serious opposition in the developer community, and users are broadly enthusiastic.
With the code for the upgrade completed and pushed to the Bitcoin software in in January (Bitcoin Core 0.21.1), all that remained was for the network to activate the upgrade. Due to both technical and philosophical disputes within the developer community on how the network should upgrade, though, activation discussions became heated and took several months.
BIP 8 agreement. A rough agreement among developers emerged that Bitcoin Improvement Proposal 8 (BIP 8) should be used to activate the upgrade. This method allows miners to activate the upgrade by signaling they are ready, with a period of time allotted for miners to reach a threshold of approval. However, what should be done if miners don’t approve the upgrade by the end of the allotted time period? Two divergent views emerged around handling a lack of miner activation: 1) allow it to expire and start over with a new activation method (“LOT=false”), or 2) force an upgrade by having nodes enact their governance power over the network by rejecting blocks that don’t enact Taproot (“LOT=true”). The delta between these two concepts illustrated a philosophical debate in Bitcoin: who should control Bitcoin’s development, and who should be responsible for adding upgrades? Should we let miners signal they are ready to activate the upgrade to ensure they are on-board, or should users force upgrades? And at what point, if at all, should users force upgrades? The “LOT=false” camp believed there was time to let miners signal before more drastic measures, like enacting another user activated soft fork, were required to force activation. The “LOT=true” camp, by contrast, was amenable to giving miners time to signal, but wanted to prepare now to force their hands with a user activated soft fork should they fail to enact it.
Speedy Trial compromise. In the Spring, a compromise emerged called “Speedy Trial.” The idea was for an accelerated timetable for miner activation. Speedy Trial allowed miners to activate Taproot if 90% of blocks in a given difficulty epoch (2016 blocks, about every 2 weeks) signal for Taproot activation, but that signal needed to occur before August 11, 2021. If more than 90% of blocks contained in any one of the expected 6 difficulty epochs (2-week periods) before August 11 signaled for Taproot, the upgrade would “lock-in” and then activate automatically at block height 709,632. If no difficulty epoch received 90% affirmative signaling, then the Speedy Trial method would fail, and other methods would be explored. The goal here was that Speedy Trial will either succeed or fail quickly. LOT=false supporters were amenable to Speedy Trial because it’s essentially the same as other LOT=false implementations, i.e., it doesn’t force activation at the end of the signaling period. LOT=true supporters were mostly on board with Speedy Trial because it would succeed or fail quickly enough to leave plenty of time for a user activated soft fork.
Upgrade and Adoption Timeline
Ultimately, Speedy Trial was successful, with more than 99% of Bitcoin hashrate signaling affirmative, and Taproot “locked in” on June 12, 2021, which made activation inevitable. Indeed, shortly after midnight on Sunday, November 14, 2021, Taproot did officially activate on the Bitcoin network. Currently, more than 55% of nodes are enforcing Taproot rules, meaning they are running Bitcoin Core 21.1 or later. Until nodes upgrade to support Taproot, they (nodes) will be unable to enforce Taproot rules, but the network will run just fine until they do.
Just because Taproot is live now doesn’t mean most users can make use of its features. Wallets need to add support for Taproot addresses (P2TR) and create UX to utilize the many advantages the upgrade brings.
Some major services have already announced support for Taproot, though, including cryptoassets custodian BitGo. Bitcoin engineer Tyler Levine wrote in a blog on November 12, 2021 that BitGo would have “full API support for both sending and receiving on Taproot addresses” almost immediately upon launch. Shortly after Taproot activation on Sunday, November 14, 2021, BitGo tweeted that it had made its first ever mutli-signature Taproot transaction. It makes sense for custodians to be early adopters of Taproot because, as some of the network’s most prolific users of complex transactions, they stand to gain the most from the upgrade’s scalability enhancements.
However, the rest of the network is likely to be slow to follow. Our best comparison is the 2017 segregated witness (SegWit) upgrade. It took about 2 years before SegWit usage reached 50%, and another 4 years to reach 80%.
Bitcoin is Built to Last
More than any other, the bitcoin community is fixated on preserving the network’s long-term resiliency. This is mostly achieved through a focus on decentralization, scaling through compactness and layering, and privacy enhancements that do not jeopardize Bitcoin’s monetary policy. Software upgrades that place undue burdens on nodes are eschewed. All upgrades should be completely backwards compatible. This community ethos makes Bitcoin incredibly durable, secure, and reliable over longer time horizons. Bitcoin’s critics, many altcoin founders and promoters among them, often point to this development style as rigid and un-innovative, lacking in the composability that has given growth to phenomena like DeFi. This is a fair criticism, but to achieve these features, whether enhanced programmability or transaction throughput, often entails protocol design decisions that result in more centralization—a tradeoff that bitcoiners reject.
Importantly, upgrades like Taproot make clear Bitcoin isn’t only maintaining its decentralization by rejecting the centralizing tradeoffs that alternate layer 1 blockchains consider in their design decisions; Bitcoin is actively upgrading to become more resilient. Bitcoin is moving in a different direction than other Layer 1 blockchains. By focusing on hardening, by becoming more compact and private, and by maintaining an ethos of avoiding hard fork upgrades, Bitcoin differentiates itself further from the technology competition of other protocols.