About Bitcoin
Taproot v2: how will the latest Bitcoin upgrade evolve in the future?
By Josef Tětek — Bitcoin just got better with Taproot, but what’s next? Let’s look at some of the other improvements now being developed.
Taproot activated recently on Sunday November 14th (block #709,632). The latest Bitcoin upgrade brings a lot to be excited about — but that’s even more true for the future versions of Taproot. In this text, we explore potential future iterations of Taproot and what they might bring to Trezor users.
Contents
- SegWit versioning
- CISA: all bitcoin is created equal
- Graftroot: signature delegation
- OP-CAT: Quantum resistant Bitcoin
- SIGHASH_ANYPREVOUT: Improved Lightning Network
SegWit versioning
When Segregated Witness (SegWit) was implemented in Bitcoin in 2017, it came with a versioning system: the first SegWit version was v0, and subsequent versions were expected to follow. The reason for introducing the versioning system was to make implementation of new opcodes in the future smoother and in line with the existing validation rules.
The formal proposal for Taproot is actually called SegWit version 1 spending rules, because that’s what it is: a further expansion of the original SegWit. An update to the Bitcoin protocol done in this fashion ensures the least disruption as Bitcoin nodes are already familiar with the peculiarities of SegWit-type transactions. The smooth rollout of the Taproot update has proven that Bitcoin can update this way without any contention and disruption, which is very promising for future updates.
And future updates of Taproot, i.e. future updates to SegWit, are sure to follow. The recently activated Taproot brought only the most necessary and time-tested technologies such as Schnorr signatures and Merklized Abstract Syntax Trees (MAST), but left many more promising updates on the table. As Bitcoin core developer Gregory Maxwell explained in a Reddit post:
[A] fairly large amount of known-useful functionality was stripped out of the taproot proposal in order to have something that was entirely free of new research or difficult trade-offs in order to get it done quickly and get feedback from real usage that could inform the next version.
Still, the recent Taproot upgrade is quite powerful. To briefly recap, these are its main benefits:
- Schnorr signatures allow for signature aggregation (useful in multiple ways);
- multisigs and opening or closing of Lighting Network channels becomes indistinguishable from simple spends;
- major improvements in hardware wallet transaction signing and broadcasting speed, making CoinJoin capability practical to implement in hardware wallets;
- elimination of a potential fee exploit;
- introduction of new opcodes into Bitcoin becomes more straightforward with Tapscript.
CISA: all bitcoin is created equal
One of the most exciting future Taproot-enabled upgrades is called Cross-input signature aggregation (CISA). Under the current iteration of Taproot, it becomes possible to aggregate multiple signatures spending one input into a single signature — making complex transactions such as multisigs and Lightning Network channel management more private and cheaper.
CISA would allow for signatures of multiple inputs to be aggregated into a single signature. While this may sound like a minuscule improvement over the current signature aggregation, its consequences would be massive in terms of fee savings and user privacy.
First of all, ordinary Bitcoin transactions would benefit from CISA, as even simple spends can involve multiple inputs: every time a user spends a larger amount of bitcoin than they ever received in a single transaction (i.e. they have no single unspent transaction output- UTXO — of sufficient denomination), they inevitably need to use multiple inputs in their transaction.
Currently, every single input must be accompanied by an individual signature, taking up scarce blockspace that needs to be paid for in transaction fees. With CISA, only one signature would be required even if multiple inputs were used, with significant savings in transaction size and corresponding fees.
CoinJoins would benefit heavily from CISA, as a CoinJoin round is essentially a single transaction with many inputs. With cross-input aggregation in place, CoinJoins would become much cheaper to participate in, even to the point where CoinJoin spending could become slightly more fee-efficient than an ordinary spend.
This incentive would greatly expand the CoinJoin anonymity set above where it stands today (one of the most popular CoinJoin pools — Samourai Whirlpool — only contains 4,350 BTC at the time of writing, per Clark Moody’s dashboard). With ubiquitous CoinJoins, chain surveillance in its current form would become nearly impossible.
Lastly, cross-input aggregation would mean that UTXOs of small denominations (hundreds or lower thousands of satoshis) would be cheap to consolidate and construct a larger-denominated UTXO from. Note that this would only apply to UTXOs on Taproot addresses — the “dust” on legacy or SegWit addresses wouldn’t be helped by this.
CISA wasn’t part of the current Taproot iteration mainly because more time is required to understand all its consequences (see the second half of this Reddit post for an overview of CISA’s pros and cons).
Graftroot: signature delegation
One of the not-yet-satisfactorily-resolved problems of holding bitcoin over longer time frames is a key handover process that would prevent coins from being lost while uncompromising on the security and privacy. Shamir backup was a major first step in this direction, but even such a solution is susceptible to gradual erosion — multiple shares may be lost over the decades, especially if the whole inheritance plan isn’t regularly maintained and the survivors aren’t well-informed about the nature of their potential inheritance.
Graftroot may be the silver bullet for inheritance planning and other use cases requiring graceful handover of control over specific coins. Proposed by Pieter Wuille in 2018, Graftroot would allow users to delegate their ability to sign to a surrogate script which would define alternative ways to spend from the Taproot script — even after the script was created.
This means that a Taproot address owner could delegate the spending from said address to his survivors without having to perform any onchain transaction and handing over any sensitive data such as mnemonic seed words — the whole plan could be kept secret, have multiple fallback plans, and come with timelocks (so that the prospective survivors wouldn’t be able to spend the coins before the original owner’s demise).
Inheritance planning is only the most obvious use case of safe and private delegation. With the possibility to delegate to multiple surrogate scripts without revealing anything onchain and after the delegated script is already deployed, we can only speculate what further use cases we would see emerge.
The Graftroot idea has been lately expanded upon with Generalized Taproot and Entroot proposals, and the discussion around the optimal form of Taproot-enabled delegation is still ongoing.
OP-CAT: Quantum resistant Bitcoin
The concern over quantum computers has been going around for years, mostly leveraging the fact that currently utilized signature schemes (both ECDSA and Schnorr) are susceptible to the theoretical threat of sufficiently-advanced computers breaking the cryptography.
As Jeremy Rubins argues in his recent blog on the topic, a previously disabled Bitcoin opcode called OP-CAT could help in this regard. As we mentioned above, Taproot brings an easier implementation of new opcodes, and OP_CAT is among those under consideration, as it could help with use cases such as those described by Rubins.
SIGHASH_ANYPREVOUT: Improved Lightning Network
A part of every bitcoin transaction is a signature hash (sighash) flag that defines what parts of the given transaction the signature signs and thus cannot be modified later (as the modification of such parts would make the previously made signature invalid). The default is SIGHASH_ALL, where everything in the transaction is signed and no element can be adjusted later on. But there are use cases where the ability to change certain elements of the transaction without invalidating the signature is useful.
One of these use cases is Eltoo, a proposal for a better Lightning Network update mechanism. Described in 2018, Eltoo improves upon the current, penalty-based mechanism used to update the channel state between the participating Lightning nodes. The problem with the penalty-based system is that inadvertently broadcasting an old channel state (e.g. after an outage) can result in a loss of funds, even though there was no intent to misbehave in the first place. This can cause a lot of frustration for the users and is an obstacle on the road to broader adoption.
Eltoo removes the need for penalties while still protecting users from potential misbehaviour. But the stepping stone to Eltoo is an implementation of a new sighash called SIGHASH_ANYPREVOUT, as that would allow signing a transaction without committing to the transaction inputs (for a more detailed explanation, listen to this recent Bitcoin Explained episode).
The implementation of SIGHASH_ANYPREVOUT has been formally proposed since 2017 as BIP118 and its activation as part of the next Taproot iteration is quite probable.
Summary
Increased privacy at lower cost, quantum resistance, and an improved Lightning Network — these are some of the most promising areas that future Taproot iterations will bring over time.
Recently we discussed Taproot at length in a Twitter Space alongside experts from Braiins and Slush Pool — listen to the full talk below!
It’s impossible now to say which of the proposals discussed above will find their way to the Bitcoin protocol and when it will happen, but one thing is certain: only the proposals that greatly improve the network — without sacrificing the key elements of decentralization and user sovereignty — will make it through the rigorous peer review process. And while some companies in the Bitcoin space might be slow to adopt these upgrades, Trezor is at the forefront of implementing Taproot for the benefit of its users.
