Most Influential: The Developers Who Wrote Bitcoin’s Taproot Upgrade
Bitcoin developer Jonas Nick has a t-shirt emblazoned with the following:
Gobbledygook? Hardly. It’s the full reference Schnorr signature verification code contained in Bitcoin Improvement Proposal (BIP) 340
Nick, along with A.J.Towns, Tim Ruffing and Pieter Wuille are the authors credited for writing the three BIPs that made up Taproot, the most significant Bitcoin upgrade in four years.
This article is part of CoinDesk’s Most Influential 2021 list. Stellabelle’s portrait of the Taproot developers is available at Foundation with 15% of the sale going to charity.
Proposed in 2017 by seminal developer Greg Maxwell, Taproot was merged into Bitcoin Core, the most widely used implementation of the network’s software, in October 2020, locked in on June 12, 2021,and then finally activated on Nov. 14. With Taproot, Bitcoin has gained a valuable set of tools for developers to integrate new features that will improve privacy, scalability and security on the original, and most valuable, cryptocurrency network.
True, the changes to Bitcoin fall squarely in the “techy” and “future potential” categories, rather than the immediate and tangible. But when it comes to evaluating some of the most important developments in Bitcoin this year, the work of Wuille, Towns, Ruffing and Jonas to make Taproot happen cannot be overlooked.
Read more: Taproot, Bitcoin’s Long-Anticipated Upgrade, Has Activated
Meet the developers
Pieter Wuille
Pieter Wuille contributed to all three of the proposals that made up Taproot and took on a lead role in the process. Soon after his introduction to Bitcoin in 2010, he became a prolific contributor to Bitcoin Core’s codebase. Not only did he help ensure the success of Taproot this year, but he also was a major contributor to Segregated Witness (SegWit), a major soft fork that gave Bitcoin a more efficient way to store data; in fact, CoinDesk recognized Wuille on its Most Influential list in 2017 as well.
Wuille has a Master of Engineering in Computer Science degree from KU Leuven, a leading university in Belgium. He co-founded blockchain infrastructure company Blockstream in 2014 and was its core tech engineer before moving over to Chaincode Labs in 2020.
Jonas Nick
A developer at Blockstream since 2015, Jonas Nick also works on libsecp256k1, a cryptographic library that is used in Bitcoin Core. He is involved in researching and implementing cryptographic schemes such as MuSig2, which allows multisignature (multisig) wallets using Taproot to be indistinguishable from regular wallets. LIke Wuille, Nick is listed as an author on all three Taproot BIPs.
Tim Ruffing
Tim Ruffing is a cryptographer for Blockstream with a PhD in computer science from Saarland University in Germany with a focus on cryptography in Bitcoin. His chief contribution to Taproot was as co-author of BIP 340.
Anthony Towns
Anthony Towns is listed as a co-author on BIPs 341 and 342. He is a proponent of decentralization in Bitcoin with a focus on “keeping Bitcoin stable and secure.” To that end, he recently joined the Digital Currency initiative, a group that “aims to provide long-term funding for a moderate-sized team of senior devs and researchers.” There he will lead its Bitcoin software and security effort.
How it started
Let’s go back to Nick’s t-shirt for a moment.
At the heart of Taproot is a piece of cryptography called Schnorr signatures. These signatures were first described by Clause Schnorr in 1991 and offered a simpler, more efficient signature alternative to Bitcoin’s ECDSA scheme.
A “digital signature” is how a user signs a transaction using a private key to approve sending data (like a message or a cryptocurrency) somewhere else.
Following the upgrade, every transaction using Taproot will now use this new Schnorr digital signature scheme, adding capabilities designed to boost the privacy, security and scale of Bitcoin transactions.
In addition to being smaller and faster than ECDSA, Schnorr signatures have the added benefit of being “linear,” a combination that will boost Bitcoin’s transaction privacy and allow for more lightweight and complex “smart contracts” (encoded contracts with self-executing rules).
Read more: How Bitcoin’s Taproot Upgrade Will Improve Technology Across Bitcoin’s Software Stack
According to Wuille, the germ of the idea for Taproot emerged over lunch with Maxwell and fellow dev Andrew Poelstra. Over the following months, Ruffing, Nick and Towns joined the conversation and in May 2019, they published the first drafts of the three proposals that would eventually become Taproot.
“It was immediately clear to me [the idea] should work,” said Ruffing in an interview with CoinDesk. It was just a matter of working out the details, he said.
Ruffing had been working on cryptography in Bitcoin since 2013. For him, contributing to Taproot was a natural fit.
As I added more and more, I eventually was added as an author,” he said.
What the devs gave us
The three Bitcoin Improvement Proposals are numbered 340, 341 and 342. Each BIP has a specific function, but they all work together to create the upgrade known as Taproot.
Authored by Wuille, Nick and Ruffing, BIP 340 specifically proposed the standard for 64-byte Schnorr signatures instead of the previous ECDSA signatures. In the BIP, the authors outlined Schnorr’s advantages over ECDSA, namely its provable security, non-malleability and linearity.
Linearity is one of the more interesting of the three features of Schnorr signatures. This means multiple collaborating parties can produce a signature that combines all their public keys, with major implications for privacy and efficiency, especially when it comes to multisignature (multisig) transactions.
“For all these advantages, there are virtually no disadvantages, apart from not being standardized,” the BIP 340 authors state. And the point of the BIP was to standardize Schnorr signatures.
Written by Wuille, Nick and Towns, BIP 341 proposed a new Segregated Witness (SegWit) version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches (part of the cryptographic scheme that generates the hashes that encode data on the blockchain.) SegWit, the previous major Bitcoin upgrade, essentially allowed for larger blocks of transactions every 10 minutes or so by paring down the amount of data required per transaction signature.
BIP 341 enables the newest upgrade to work efficiently and securely with SegWit by adjusting certain spending rules and improving the privacy, efficiency and flexibility of Bitcoin’s scripting capabilities so that the two upgrades work together without a hitch.
Finally, BIP 342, written by Wuille, Nick and Towns, “specifies the semantics of the initial scripting system under BIP 341.” In other words, it ensures that all of Bitcoin’s operational code will ultimately work properly with all the new changes.
When you put these three BIPs together, you get a powerful set of new developer tools for Bitcoin.
Read more: What Taproot Could Mean for Bitcoin Investors
“First of all, it’s a privacy thing,” said Ruffing. By incorporating Schnorr signatures, he explained, a multisig public key now looks like a normal public key, and a multisig signature looks like a normal signature; that is, anyone looking at the blockchain (ahem, forensic analysts) won’t be able to tell if it’s one person signing the transaction or if it’s a group.
For example, although Lightning Network channels operate on a second layer apart from the Bitcoin base layer, they still have to open and then finally settle on the main chain. For that, Lightning Network transactions on the main chain requires a multisig (2 of 2) transaction. With Schnorr signatures and signing protocols such as MuSig2, those transactions can appear just like any other “vanilla” transaction, and no one will be able to identify them on the blockchain as “open channel” or “close channel” Lightning transactions.
Second of all, “it’s an efficiency thing,” said Ruffing. Previously, in a multisig transaction, each of the keys of the parties involved would have to be listed out separately. That’s a lot of data. Now, by combining all these keys into one key, each transaction takes up less space, so more transactions can fit into each block.
This efficiency is also brought to bear on different forms of smart contracts. Merklized Abstract Syntax Trees (MASTs) improve smart contracts in bitcoin, making it easier for users to set more complicated conditions for a transaction. MASTs take all the various conditions set forth in the contract and arrange them into a “tree” – but then only hash the “tip” of that particular tree, without having to include (and expose) all those different rules and parameters on the blockchain.
Then, Schnorr signatures will make even that MAST transaction look like any other normal transaction.
Why Taproot?
“There’s a very high barrier to accepting soft forks into the Bitcoin Core repository because such updates need consensus from the community,” said Nick in an email.
“When Taproot was proposed it seemed like it would be possible to get overwhelming community support because it is relatively simple and it is an obvious improvement in terms of efficiency and privacy.”
That confidence was not misplaced. From the outset, the proposed Taproot changes were pretty well received. That’s not to say that there wasn’t a rigorous and lengthy discussion and debate period. After all, it still took almost four years for Taproot to activate, from start to finish.
“It was nice to see people liked the idea,” said Ruffing. “Especially after the previous [SegWit] soft fork. There was no political discussion. Just a lot of debate – as it should be.”
The closest Taproot came to a political debate was not with regards to its actual technological proposals; rather, the debate focused on how the upgrade would be implemented and who would be the ultimate arbiter of “acceptance” – the miners? The node operators? Both?
Read more: Bitcoin Miners, Developers Narrow Down How Taproot Will Be Activated
“People knew they were setting a precedent,” said Ruffing. “It was good this discussion happened.” Still, he chose to stay away from the drama of the debate. “I thought it was a better use of my time to work on cryptography. All the arguments were already there.”
Ultimately, the Bitcoin community settled on a method dubbed “Speedy Trial” wherein the miners were given a set timeframe to “signal” their support for Taproot by adding a little bit of data to every block they mined. Once 90% of the miners signaled support, which happened on June 12, the code for Taproot was “locked in” and all Bitcoin nodes were given three months to upgrade to the latest version of Bitcoin Core, 21.1, which contained that code, before it activated on Nov. 14.
How it’s going
“Activation went pretty well,” said Ruffing. “The blockchain didn’t stop, no money was lost, there were no bugs. This was expected, but it was still nice to see.”
Node uptake has been a bit slow – about 55% of all nodes have upgraded their software to 21.1 – but the real test will be developer adoption.
“It’s very interesting to see that developers are already making use of Taproot’s features,” said Nick. “This shows that there’s actually user demand for better privacy and cheaper transactions. Taproot added a lot of upgrade paths.”
Read more: After Taproot, What’s Next for Bitcoin’s Future?
For example, says Ruffing, Taproot’s multisig improvements are “useful to have” and he expects to see more product developers taking advantage of them. “Lightning Network wants to use it. Wallets want to use it.”
To that end, Ruffing, Nick and fellow developer Yannick Seurin are working on an implementation of MuSig2, a process which uses Schnorr multisignatures and allows a group of signatories to produce a joint signature on a joint message in an efficient and highly secure way. It’s not yet finalized, but it’s close, said Ruffing.
Ruffing and Nick are also working on cross-input signature aggregation (CISA) which will further boost the space-saving potential of Taproot transactions. This development could have the added benefit of making CoinJoins – transactions that mix coins from multiple senders to obscure who sent what to whom – not only more private but also less expensive and thus, more attractive to users.
“I think we will be surprised by the things people are building that we do not anticipate,” said Nick.
“Schnorr signatures alone open a zoo of possible crypto schemes that is far from being sufficiently explored. How these abstract schemes will lead to actual improvements for Bitcoin users is something I will pay close attention to.”
