Last week, Taproot, one of the most important upgrades in Bitcoin’s history, was activated. But what it actually does is difficult to understand and not infrequently misrepresented. We therefore asked an expert.
Last week, Taproot was activated, one of the biggest Bitcoin upgrades of all time, which the community has been eagerly awaiting for years. But what exactly is Taproot? And what does it do?
Anyone reading the news about Taproot with this question in mind will reap quite a bit of confusion. So this article starts with a little overview of what the others are writing.
When press agencies are already reporting on a bitcoin upgrade …
One of the most notable features of Taproot is that it is the first Bitcoin upgrade that was newsworthy to the press agency DPA. This explains why you suddenly find information about Taproot in almost every medium, from the Süddeutsche and FAZ to the Wiener Standard and the small-town Gazette. Or, rather: misinformation.
Taproot, explains Finanzen.net, has a “far-reaching significance for the Bitcoin blockchain”. The upgrade makes Bitcoin “even more agile and flexible” and paves “the way for important technological innovations.” The FAZ and many other newspapers quote the DPA report that the upgrade brings “more privacy, less storage requirements and falling costs.”
All this remains so vague that it can be neither wrong nor right. If one wants to know more concretely, one learns rather less, and if so, then gladly wrong or misleading. Finanzen.net, for example, says that Taproot “generates only a single public key for payments instead of several public keys […]”, which, apart from the confusion of terms, is at best only half correct. Furthermore, Taproot enables “more complex smart contracts on the Bitcoin blockchain”, which is why Bitcoin could possibly soon compete with Ethereum.
In the FAZ, one learns that the Schnorr signatures “provide more privacy for Bitcoin”. The newspaper and the DPA asked blockchain professor Philipp Sandner for a statement on this, and he lectured that “these Schnorr transactions … release a bundle of transactions with a single signature”. Even a professor can sometimes be so wrong that one doesn’t know where to start.
The most competent source of information about Taproot is Heise. The IT magazine explains that the upgrade introduces the “Pay-to-Taproot (P2TR) transaction type”, “which combines the concepts of Schnorr signatures and ‘Merklized Alternative Script Trees’.” But even Heise flounders when the magazine claims that Taproot increases transaction privacy or that Schnorr allows you to sign a transaction with an aggrieved signature.
This is half-true at best, and more importantly shows how difficult it is to understand – and explain – a technically sophisticated upgrade like Taproot.
Upgrade like a wrap
We’re trying to bring a little order to the Taproot chaos. To do this we got in touch with Mark Erhardt, also known as Murch on the internet. Mark works in New York at Chaincode Labs, having previously worked for BitGo in Palo Alto. It’s hard to get any closer to the centres of Bitcoin development than the Baden native.
Mark has helped us not only to better understand Taproot conceptually, but also to grasp what the upgrade now means in concrete terms.
What is Taproot changing? What are the benefits of the update?
Taproot roughly consists of two components: Schnorr signatures and a script tree. Both components are independent of each other, but they work together, and each one is not easy to understand. This is one of the hurdles to understanding what Taproot really does – and what it doesn’t.
Schnorr – the better ECDSA
Schnorr signatures are the easiest to understand. These were around, Mark explains, before the signature algorithm ECDSA used by Bitcoin.
“The signature process is super interesting, but the inventor, Klaus-Peter Schnorr, patented it. Because the patent fee was too expensive, other cryptographers invented ECDSA to also sign based on elliptic curves. In the meantime, however, the patent protection has expired.”
ECDSA is good, very good in fact, which is why Satoshi chose the algorithm for Bitcoin. But it’s not quite as good as Schnorr, and without the patent protection, there probably wouldn’t have been a reason for anyone to use ECDSA instead of Schnorr.
The most important difference lies in a small but partly crucial detail: “The signatures are not linear in ECDSA, they are in Schnorr,” Mark explains. “If a signature scheme is linear, you can aggregate multiple signatures so that the aggregate allows you to check. You can’t do that with non-linear schemes, like ECDSA.”
So, theoretically, what the FAZ and Heise claim is true: one could aggregate all signatures in a transaction into one through Schnorr. Currently, if a transaction has many inputs – so it combines many coins – you have to sign each input and write each signature to the blockchain. That accounts for a lot of the transaction data. Schnorr could actually change this.
Could! Because “unfortunately, this aggregation didn’t make it into the Taproot upgrade,” Mark clarifies. “That would have required additional definitions and discussions, so they decided to do it later. “
Signatures secretly aggregate
Nevertheless, aggregating Schnorr signatures with Taproot is already possible now. But just not for normal transactions, only for multisig transactions. Multisig means that two or more parties have to sign a transaction so that coins can be issued from a special address (multisig address).
“Let’s say we create a wallet together where we can only spend money if we both sign. That would be a ‘2 by 2 multisig’. Thanks to Taproot, we can aggregate our public keys: You give me your public key, I combine it with mine, and the result is indistinguishable from a normal address. So you can’t tell it’s a shared wallet.”
This “not being able to tell” is the definitive reason why Taproot is said to improve privacy.
Previously, multisig addresses could be easily recognised. They started with a three, rather than a one like traditional addresses. SegWit has softened this a bit, as a SegWit address format also starts with a 3. Still, the different address types create differences that partially undermine Bitcoin’s privacy.
With Taproot, such differences can be levelled out completely. No matter what output conditions an address embodies – one signature, multiple signatures, timelocks, smart contracts – they all look the same.
But Schnorr signatures alone are not enough for this. For these are only effective for simple multisig constructions: “2 of 2”, “3 of 3”, and so on. In practice, however, other models are more popular, namely so-called threshold signatures, such as “2 of 3”: A third party has a backup key and steps in if another key is lost, or arbitrates if the other two disagree.
In such models, aggregation by Schnorr signatures does not work. So at this point we need to talk about the second part of Taproot: the script tree.
A script tree for the other cases
Mark’s former employer, wallet provider BitGo, offers a classic “2 of 3″ construction: there are three keys. One is held by the customer, one by BitGo, and the third is a well-secured, cold-stored backup. Of these three keys, two are needed to send a transaction, which are usually those of the client and BitGo.
With BitGo protection, the users’ funds are completely safe with us and makes CoinDCX, one of the safest cryptocurrency exchanges in the world. BitGo CoinDCX TryCrypto pic.twitter.com/Z4X2tpclix
– CoinDCX: Making Crypto Accessible to Indians (@CoinDCX) November 18, 2021
“There is an expectation as to which two keys will be used. This can now be served with aggregated Schnorr signatures. So we form a P2TR output with the keys from you and from BitGo, and when the normal case occurs, we can sign with an aggregated signature.”
This way of signing transactions by two parties is the most elegant, simple and beautiful way of doing it. In comparison, the current method using “P2SH” (pay-to-script hash) addresses is downright monstrously complex.
But what if it comes to the backup case? If I lose my key and BitGo signs with the backup key? Or if BitGo fails and I have to bring the backup key into play?
“These other, non-expected paths are woven as leaves into the script tree that Taproot has introduced,” Mark explains. And of course, this explanation cries out to be explained itself.
From the leaves to the root
A script tree is basically “just” a Merkle or hash tree of scripts. But what is a hash tree?
A hash tree is a special arrangement of a large number of hashes. For example, let’s say we have four bitcoin transactions and we hash them. Then we would have four hashes. In a hash tree, they are called the “leaves”.
The goal of the exercise is to advance from the leaves to the branches to the root of the hash tree. To do this, we first join the first and second hash together and hash that. We do the same with the third and fourth. The two hashes that we have as a result – the branches – we also hash. This gives us the root: a hash that stands for a multitude of hashes.
This hash tree looks like an upside-down tree: The crown is at the bottom, the root at the top. Image from wikipedia.org, licence: Creative Commons
What does such a root do? It allows a single hash to prove a variety of data. An example is a Bitcoin block: the miners take a large amount of transactions – usually a few thousand – and form the root of the hash tree from them. This root is the basis of mining, and it allows anyone to check whether a block is valid.
In the scriptbaim introduced by Taproot, each “leaf” is a way to spend Bitcoins – a script. The multisig address mentioned above contains not only the aggregate of two public keys, but also the root of the script tree.
Now, if the non-expected case happens that I sign with my and the backup key because BitGo fails, the following happens, Mark explains: “I reveal the corresponding script, which is stored in a leaf of the script tree. To prove that the original address encodes these output conditions, I reveal the hashes of other leaves and branches so that the root can be reconstructed. Then I satisfy the script contained in the leaf with signatures from the two keys.”
So we have a procedure where multisig transactions are usually – when the expected case occurs – more elegant, simpler and also more private. Only in the non-expected cases does the script tree kick in. The result is similarly complex as the P2SH method – but it is somewhat more private.
Because with P2SH, the entire script is hashed, which contains all the possibilities of how coins are to be spent. In order to write a valid transaction, I have to show the pure text of the script. So I have to make public which public keys are involved, even if they are not used at all.
With P2TR, on the other hand, it is enough if I write the option that actually occurs in plain text in the transaction. All other options remain obfuscated.
The breakthrough for multisig
There is no need to debate whether Taproot is elegant. It is. The script tree is a useful addition to Schnorr signatures. It’s understandable that a developer like Mark is excited about Taproot and can’t wait for the upgrade to arrive in all wallets.
But those for whom technical elegance is not an end in itself, but a means, are now likely to ask: what’s the point in real terms? So what can Bitcoin do better now with Taproot than before?
“Multisig is a much more secure standard to manage money,” says Mark. “You can create backups, and make it harder to spend money. It makes you less vulnerable.”
Until now, however, multisig methods had significant drawbacks: they were often complex, both for the user and the developer, they limited privacy and cost more in fees. All these disadvantages disappear with Taproot. “You give away less private information, you reveal less about your setup, and you can do more with less data on the blockchain.”
Mark hopes Taproot will help Multisig break through. That more wallets will adopt Multisig, there will be better standards, and that the user experience, which is currently often still grotty, will get better.
What Taproot doesn’t do
Despite all the enthusiasm, Mark warns against exaggerated and false expectations. Which brings us back to where we started. On the DPA report and its interpretation in the newsrooms.
“Sometimes it is said that Taproot brings DeFi to Bitcoin because it enables smart contracts. This is wrong. Smart Contracts already exist, and everything Taproot can do was possible before – it was just more complicated, more expensive and less private.”
There are also some misconceptions circulating about privacy with Taproot. “Yesterday I read in a major German newspaper that Bitcoin is becoming more anonymous because of Taproot. That is also not true. It’s true that you can no longer see whether one or more parties are signing. But the address is still pseudonymous and you can still see which coins are being issued. “
Bitcoin is 13-year-old tech!
It is bloated, lacking in privacy and fungibility, slow and cumbersome.
Trying to fix its design flaws with Layer 2 kludges is a joke 🤡EpicCash is lean, agile, private blockchain – all on Layer 1 💪😎🚀LightningNetwork Taproot BTC Crypto pic. twitter.com/gBeDqIKvut– EpicCashOfficial (@EpicCashTech) November 24, 2021
Blockchain analysts will have no problem analysing and clustering wallets and addresses as before, even after Taproot. “You just learn a little less about the setup under the bonnet. Whether it’s a normal address, a Lightning channel or a multisig setup, you can’t see it anymore. But the general traceability of the money flow remains the same. “
no, everything alts do won’t be built “on Bitcoin”.
RSK, Stacks etc are not “on Bitcoin”
and Lightning, RGB, DLCs, Taproot etc can’t really _do_ much
and no, all coins aren’t “less hard money”. most coins/tokens issued today aren’t even trying to be money.
welcome to 2021
Sry
– eriverse (@ercwl) September 23, 2021
Now it’s the ecosystem’s turn
As is so often the case with Bitcoin, it takes some time for an upgrade to reach wallets and users. Just think of SegWit. The upgrade took a long time to roll out to a large proportion of transactions, and even longer for support for bech32 addresses to be widely rolled out.
Murch hopes it will be quicker for Taproot. “BitGo wallets can already receive coins with Taproot. This shows that it can be faster this time.”
To understand what this is all about, and why it’s not straightforward, you need to know a few more technical details. At the risk of overwhelming you, we need to talk about the address formats involved.
- The default addresses are called “Pay-to-Public-Key-Hash” (P2PKH) and start with a 1.
- The “Pay-to-Script-Hash” (P2SH) addresses we have already talked about start with a 3. These were used for multisig and other smart contracts like time-locks.
- SegWit was also initially built on addresses that started with a 3: The “Nested SegWit Addresses” or – sorry: “Pay to Script Hash Pay to Witness Public Key Hash” (P2SH-P2WPKH). Here, more or less the script for SegWit was hashed and transferred into a P2SH address. This allowed SegWit to be introduced in a less disruptive way.
- The native SegWit-v0 addresses, or Pay to Witness Public Key Hash (P2WPKH) addresses, which technically work more efficiently, use the bech32 format. This newly developed standard looks completely different, the addresses are longer, consist only of lower case letters and start with “bc1”.
Pay-to-Taproot (P2TR) also uses the bech32 standard. However, there is a slight difference in the generation of the addresses, which is why the v0 addresses used so far are not compatible. This is intentional to prevent anyone from losing money.
“In preparation for Taproot, we discovered that some wallets were ignoring the Witness version in bech32 addresses and always defining outputs as Native-Segwit-v0,” explains Mark. “If one of these wallets had sent money to a P2TR address, the P2TR script would have been encoded in the output, but would have required the completion of a P2WPKH script to spend because of the version error. The recipient would not have been able to spend the money.”
For Mark, it is therefore important that as many wallets as possible first allow money to be sent to Taproot addresses. Because until this is widely possible, it will always be disadvantageous for users to use these addresses.
The core developers have done their job. But the work for the ecosystem is just beginning at this point.
