The Long Road to Taproot

Taproot is the most significant refinement that the Bitcoin code has received in recent years. It follows the same soft fork activation route that SegWit has used in 2017, except this time the trial involved securing 90% of the blocked mined throughout a 2016-block epoch (approximately 2 weeks).

From a technical point of view, Taproot takes the best of three major improvement proposals: Schnorr signatures (as described by BIP 340), Merkle branches (also known as MAST or Merklelized Abstract Syntax Tree, as described in BIP 114 and BIP 117), as well as new opcodes (Taproot, Grafroot, G’root, and cross-input aggregation).

As explained by Bitcoin Core developers Pieter Wuille, Jonas Nick, and Anthony Towns in their final BIP 341 Taproot proposal, their work is not an encapsulation of all previous ideas – as adding too many code changes would result in a more difficult review process and higher chances of adding undesirable bugs. At the same time, it’s not an attempt to separately push previous proposals either – too many upgrades would exhaust independent node operators, while also reducing the benefits of this selective approach. The authors of the BIP called it a “tradeoff” which “strikes balance”, but I like to think of it as a refinement which prioritizes the best features available and makes everything efficient.

Taproot is like combining three dishes without eating too much, while retaining the taste and nutritional value. And it’s another significant breakthrough in the process of making Bitcoin more efficient – instead of scaling through bigger blocks like many existing altcoins, the network seeks to make the existing small blocks more efficient and private for all users.

In a previous article, I’ve praised the activation mechanism and argued that the path to upgrade completion reflects the kind of decentralization that Bitcoin really needs to succeed as a project. In this article, I’m going to use Pieter Wuille’s short thread to tell the story of how Taproot got activated and also explain what’s next.

Taproot – from 2018 diner talk to June 2021 lock-in

As of block height 687284 (mined by F2Pool on June 12th 2021), the Taproot soft fork has been signalled by more than 90% of the miners which discovered blocks throughout an epoch. This means that Taproot will finally get activated at block height 709632, an event that is estimated to take place in the month of November (update: it took place on November 14th 2021 and the first Taproot block was mined by F2Pool).

However, the Taproot phenomenon didn’t happen over night. The idea of replacing Bitcoin’s ECDSA (Elliptic Curve Digital Signature Algorithm) with Schnorr signatures has been debated within the community for years. Satoshi Nakamoto chose the lesser efficient ECDSA because there was still a patent which prevented him to use Schnorr until 2008, and the more popular open source standard had more libraries anyway. So while his design was not ideal, it was the most practical and reasonable for its time.

Yet bitcoiners have been dreaming of adding Schnorr signatures for quite some years. A proposal has been formalized by Greg Maxwell in January 2018, just a few months after SegWit got successfully activated via UASF (User-Activated Soft Fork). Around the same time, Maxwell met with fellow developers and cryptographers Pieter Wuille and Andrew Poelstra in a diner from Los Altos, California. As described by Wuille, his peers had come up with a “really cool idea to hide Merkle roots in P2PK-like outputs” while he briefly left the table.

But in Bitcoin, the process between a successful brainstorming session and the creation of a thoroughly-reviewed proposal takes 3 years or more. Wuille formalized the first Taproot proposal in May 2019 – it was only a short message to the mailing list of Bitcoin developers, but the text already described the main features of the soft fork. Contributors to this proposal include Jonas Nick, Anthony Towns, and Tim Ruffing – all of whom stuck around throughout the entire development cycle.

After some careful testing and observation, a refined version of Taproot was created by Wuille in October 2019. This time, Wuille and his collaborators figured out more parts that may cause unnecessary complications and stand in the way of the desired efficiency (most famously, 1 byte from the initial 32 byte public key design was dropped because it “provably does not contribute to security”). Also, they quadrupled the depth of the Merkle trees for the sake of optimizing the code. The name of the Bitcoin development is efficiency, and this second version was nothing short of its goal.

The Taproot received its final changes in August 2020, when the quadratic residue tiebreaker was removed. Once again, this was all about improving efficiency. And when one feature does not provide the expected benefits and causes extra sophistication, it gets removed. This is part of the Bitcoin development ethos, according to which every line of code matters. It’s not just minimalism, but a constant quest for maximum efficiency.

By October 2020, a final version of Taproot was available for testing. Developers merged it in a preliminary testnet version of Bitcoin Core 0.21, and it was around the same time that the debates about activation became serious.

Meanwhile, all throughout the development process, independent auditors would take a look at the open source code. After all, the future of money is at play and nobody wants to allow a terrible mistake to damage the functionality of a system like Bitcoin. Bitcoiners like Max Hillebrand offered bounties to code reviewers to take a look at every line of code and make sure that nothing contentious or poorly-optimized would get included. This is part of the beauty of a decentralized and open-source system, where everything is visible and anyone around the world can contribute.

If you recall the events, it was all about showing support for LOT=true or LOT=false: in the former case, sovereign nodes could step in and reject the blocks of miners that don’t signal Taproot activation at the end of the trial period; in the latter case, there would be no consequence if miners refused to update to Taproot (thus giving them a veto power). Either way, the signalling period would have lasted an entire year.

Most of all, users were aware of the 2017 situation with SegWit. At the time, the miners refused to signal the softfork activation before the given trial time. Therefore, sovereign nodes took it upon themselves to adopt the transaction malleability fix – thus leading to the successful UASF movement.

But in the middle of these heated debates, David Harding presented a proposal for a “speedy trial” which lasts only 3 months and requires a supermajority of 90% of blocks mined during an epoch (1815/2016). This seemed like the ideal way to proceed, as everybody else seemed to agree that the Taproot code was ready and activation was only a matter of agreeing to update the Bitcoin Core client.

The speedy trial had a rocky start, with only a couple of mining pools (including Slush Pool and Foundry USA) signalling the activation of Taproot. But bitcoiners were relentless and they kept on demanding miners to signal their support. Users on Twitter went tribal and displayed their advocacy for Taproot by using the green block emoji next to their name – but after the first epoch, the situation didn’t look so good. Though F2Pool was the big player that joined the activation camp, it still wasn’t enough.

The second epoch of the trial didn’t succeed either, but it was pretty close. Around the time, mining pools such as Poolin, Antpool, BTC.com and Binance Pool were pressured into joining the signalling camp. During the final dozens of blocks of this epoch, it became clear that the third time’s a charm: unless the miners decided to backpedal on their decision to support Taproot, the activation would get imminently locked in. And that’s exactly what happened on June 12th 2021.

What’s next for Taproot?

The Taproot activation is going to take place in November 2021, at block height 709632. But until then, there’s a lot of work to be done. On the developers’ side, wallets need to be upgraded and standardized. To take advantage of the privacy advancements of multisigs, the MuSig2 format needs to receive a standard that all wallets can use. Also, the PSBT extensions need to get improved to communicate with keys, scripts, or signatures.

On the users’ side, they must update their node clients to a version which supports Taproot – the most recent being 0.21.1. This is the most important step, as all the coding and activation efforts are futile if they don’t get used to their full potential. Obviously, everything is optional and relies on the best interests of the sovereign node operator. But there are unquestionable advantages to upgrading at both the individual and the network level.

I read about Taproot for the first time in 2019, in Aaron van Wirdum’s article. It took approximately two years for the code to get refined and reviewed by the community, and another half a year until the speedy trial succeeded in locking up the soft fork for the November activation. It feels like a long time, but this is how progress is made on a decentralized and truly deliberative ecosystem. Everything must be optimized to the slightest details, while efficiency is much more important than the speed of activation or the pressure coming from market actors during various phases.

Bitcoin is the perfect example of a decentralized system which takes into account the opinions of all users and gives everybody enough time to voice their concerns and criticism. Going forward, it’s unlikely that anything will change – miners and node operators will always demand the highest standards of rigor before running a new version of the client, while developers will seize every opportunity to stand out with constructive additions or valuable criticism.

There are still improvements to be made to Bitcoin’s base layer and there are plenty of proposals, ranging from Drivechains to OP_CheckTemplateVerify. The developers are hard at work doing what they do best: making the most out of Bitcoin and extending its limits in creative and efficient ways.

Donate to Bitcoin Takeover!

Thank you for reading! If you found my work useful and would like to reward it with a small donation, there are two ways in which you can do it:

Send BTC: bc1qlnfnylexvuyu0kazdz966uksajdwah242y0rmu

Send an environmentally-friendly, cost-efficient, and Lightning-fast transaction: lnbc250u1psv0ezypp5nvghxf3jg4gv0hzmmx0x9sejk629nqemfgnrezhv92acxdy8u60sdp8f3hkueeq2ashjgr5dus9gctswfhk7apqf38zqvgcqzpgxq97zvuqsp5hlstyqmx7a7xatqptp8d9jlrhl2sxjr45nsdxqa72ujt3mep0d3s9qy9qsqwtyzajc9439vu25hsenagcr0mm8qsm2d2ntzz0gf3jh898pq38tzsc5ulacfqtthu9w8g43fv4q76h6xfuta5fgmu5d7rjjpmjtqlhgqfv7v4j

Also, if you enjoy my work then please sign up to my weekly newsletter. You’ll receive direct links to the latest articles I write, the most recent podcasts I record, and everything about the 24/7 podcast radio – straight into your inbox, so you don’t have to look for it on Twitter.