Taproot was recently activated on Sunday, November 14th (block #709632). Bitcoin’s latest upgrade brings a lot of things to get you excited – but that’s even more true of Future versions of Taproot. In this text, we explore potential future iterations of Taproot and what they might bring to Trezor users.
When Segregated Witness (SegWit) was implemented in Bitcoin in 2017, it came with a versioning system: the first SegWit version was v0, and later versions are expected to follow. The reason for introducing the release system was to make the implementation of new operating codes in the future more smooth and in line with current validation rules.
Taproot’s official proposal has actually been called SegWit Spending Rules Version 1, because that’s it: a further expansion of the original SegWit. The update made to the Bitcoin protocol in this way ensures that it is less disturbance Since Bitcoin nodes are already familiar with the characteristics of SegWit-type transactions. The smooth launch of the Taproot update proves that Bitcoin can update in this way without any controversy or disruption, which is very promising for future updates.
And Future updates of TaprootAny future updates to SegWit, be sure to keep an eye on them. The recently activated Taproot brought only the most necessary and time-tested technologies like Schnorr signatures and Merklized Abstract Syntax trees (MAST), but it left several promising updates on the table. As core Bitcoin developer Gregory Maxwell explained in a Reddit post:
[A] A fairly large amount of known useful functionality has been stripped from the main root suggestion in order to have something completely free of new research or hard trade-offs in order to get it done quickly and getting feedback from real use can inform the next release.
The latest Taproot upgrade is still very powerful. To sum up briefly, this is it Key Benefits:
- Schnorr signatures allow for signatures to be grouped (useful in many ways);
- multisigs and the opening or closing of the channels of the lighting network becomes indistinguishable from simple spending;
- Significant improvements in hardware wallet transaction signing and streaming speed, making CoinJoin’s ability practical to implement in hardware wallets;
- Elimination of potential fee exploitation;
- Introducing new opcodes in Bitcoin becomes more straightforward with Tapscript.
One of the most exciting future-enabled upgrades for Taproot is called Signature collection via input (CISA). With the current iteration of Taproot, it becomes possible to pool spending of multiple signatures single entry In a single signature – making complex transactions like multisigs and managing Lightning Network channels more private and cheaper.
CISA will allow signatures multiple The entries are grouped into a single signature. While this may seem like a slight improvement over the current signature assembly, its consequences will be enormous in terms of Saving fees and user privacy.
First of all, normal bitcoin transactions will benefit from CISA, such as Even a simple expenditure can include multiple inputs: Every time a user spends more bitcoin than they earned in any one transaction (i.e. doesn’t have the output of a single unspent transaction – UTXO – of sufficient denomination), they inevitably need to use multiple inputs in their transaction.
Currently, each individual entry must be accompanied by an individual signature, taking up limited space that you need to pay for in transaction fees. with CISA, Only one signature will be required even if multiple entries are usedWith significant savings in transaction volume and corresponding fees.
CoinJoins will benefit greatly from CISA, as a CoinJoin round is essentially a single transaction with many inputs. With cross-input pooling in place, CoinJoins will become much cheaper to participate in, even to the point where CoinJoin spending can become more fee efficient than regular spending.
This incentive would significantly expand the CoinJoin anonymity described above where it stands today (one of the most popular CoinJoin pools – Samourai Whirlpool – contains just 4,350 BTC at the time of writing, according to Clark Moody’s dashboard). With CoinJoins ubiquitous, blockchain monitoring in its current form would become nearly impossible.
Finally, cross-input aggregation could mean that UTXOs of small classes (hundreds of thousands or less of satoshis) would be cheap to standardize and create a larger class UTXO. Note that this would Only apply to UTXOs on Taproot addresses – “Dust” on old addresses or SegWit addresses will not help with this.
CISA has not been part of the current iteration of Taproot primarily because more time is required to understand all of its consequences (see the second half of this Reddit post for an overview of the pros and cons of CISA).
One of the issues that has not yet been satisfactorily resolved regarding holding bitcoin over longer periods of time is the . file Turnkey process This would prevent the loss of coins while not compromising security and privacy. Shamir’s backup was a major first step in that direction, but even such a solution is subject to gradual erosion—many shares may be lost over decades, especially if the entire inheritance plan is not systematically maintained and survivors are not well-aware. The nature of their potential inheritance.
Graftroot could be the silver lining for inheritance planning and other use cases that require agile delivery of control over certain currencies. Graftroot suggested by Pieter Wuille in 2018 for users Delegate their ability to sign to alt text Which will define alternative ways of spending from the Taproot script – even after the script has been created.
This means that the owner of the Taproot address can Delegating spending from the aforementioned address to the heirs without having to make any onchain transaction And hand any sensitive data like memory raw words – the entire plan can remain secret, have multiple backup plans, and come with time locks (so potential survivors can’t spend coins before the original owner is gone).
Inheritance planning is just the most obvious use case for secure and private delegation. With the possibility to delegate to many alternative scripts without exposing anything onchain and having already deployed the delegated script, we can only speculate on additional use cases we will see emerge.
The idea of Graftroot has recently been expanded with proposals for generalized Taproot and Entroot, and debate over the optimal form of Taproot-enabled delegation continues.
Concern about quantum computers has been going on for years, taking advantage mostly of the fact that currently in use signature schemes (both ECDSA and Schnorr) are vulnerable to the theoretical threat of sufficiently advanced computers to breach cryptography.
As Jeremy Robbins argues in his recent blog on the topic, a The Bitcoin opcode was previously disabled called OP-CAT can help in this regard. As mentioned above, Taproot offers easier implementation of new opcodes, and OP_CAT is among those under consideration, where it can help with use cases such as those described by Rubins.
A part of every Bitcoin transaction is the signature hash (sighash) that identifies the parts of the transaction that the signatures refer to and therefore cannot be modified later (because modifying these parts would make the previous signature invalid). The default is SIGHASH_ALL, where Everything is signed in the transaction No item can be modified later. But there are use cases where a file It is useful to be able to change certain elements of the transaction without invalidating the signature.
One such use case is Eltoo, a proposal to improve the Lightning Network’s update mechanism. Described in 2018, Eltoo is improving the existing penalty-based mechanism used to update channel status between participating Lightning nodes. The problem with the penalty-based system is that inadvertently broadcasting an outdated channel state (eg after a power outage) can result in a loss of money, even though there is no intent to misbehave in the first place. This can cause a lot of frustration for users and be an obstacle in the way of wider adoption.
Alto Eliminates the need for penalties while still protecting users of potential misconduct. But the starting point for Eltoo is a new sighash implementation called SIGHASH_ANYPREVOUT, because that would allow a transaction to be signed without committing to the transaction entries (for a more detailed explanation, listen to this last Bitcoin Explainer episode).
The SIGHASH_ANYPREVOUT implementation has been officially suggested since 2017 as BIP118 and activated as part of a potentially very next Taproot iteration.
Increased privacy at lower cost, quantum resistance, and Lightning Network optimization – these are some of the promising areas that future iterations of Taproot will bring over time.
We recently discussed Taproot at length in the Twitter Space along with experts from Braiins and Slush Pool – listen to the full talk below!
It is now impossible to say which of the proposals discussed above will find its way into the Bitcoin protocol and when it will, but one thing is certain: only Suggestions that greatly improve the network – Without sacrificing the core elements of decentralization and user sovereignty – you will pass a rigorous peer review process. And while some companies in the Bitcoin space may be slow to embrace these upgrades, Trezor is at the forefront of implementing Taproot for the benefit of its users.