Introduction

This is the first in a three-part series of blog posts about the latest version of Elements Core. Last week we released Elements 0.21, which is a big milestone — this is the first major version of Elements since 0.18 in September of 2019. This release is the result of over a year of sustained work, which included a complete overhaul of our process for staying up-to-date with Bitcoin Core in (near) real-time.

In addition to catching up with Bitcoin Core 0.21, this release also includes several important new features. The first, which is the focus of this post, is Taproot, whose implementation on Elements differs in some subtle and important ways. In our next post, we will discuss Partially Signed Elements Transactions (PSET), an extension of Bitcoin’s PSBT2, which allows different wallets to collaboratively blind and sign Confidential Transactions. Finally, in the last post of the series, we will describe a new set of opcodes available in Elements Script.

For some historical context, when Elements was first launched in 2015, as part of the Elements Alpha network, it included a set of new opcodes not present in Bitcoin, including all the opcodes disabled by Satoshi in 2010, plus some new ones (such as OP_CSV) that later found their way into Bitcoin itself. This release marks the first time since 2015 that we have added new opcodes, this time guided by real-world experience deploying smart contracts on Liquid.

Other features in this release, which we inherited from Bitcoin Core, include basic wallet support for output descriptors, new RPCs, Tor v3 support, many efficiency improvements, along with dramatically improved CI and QA infrastructure.

Taproot

Taproot is a new extension of Bitcoin that is scheduled to be activated at block #709,632, likely on November 17, 2021. It provides a new output type which is always in the form of a single signing key. Unlike existing output types, in which users have the choice to provide either a key or a (hash of a) script, when they are created Taproot outputs all have the same form, improving the privacy and efficiency of the system.

On Liquid, Taproot will activate after two-week-long epochs of 100% signalling in block headers. Updated functionaries will first start signalling for the epoch starting with block #1,562,400 (about November 5), so the earliest that Taproot can activate is two weeks later — November 19. We are currently working with functionary operators to make sure all the functionaries are updated in a timely manner.

The innovation of Taproot is to embed the scripting capability, which previously had to be conspicuously opted into by wallet software (for example, to support escrow payments, Lightning HTLCs or multisignature policies), inside the key itself. Under typical circumstances, the existence of this script is never revealed at all. Only if the script is needed is it revealed. To further improve this situation, thanks to the use of Schnorr signatures rather than ECDSA, script is necessary in far fewer situations than before.

When Taproot activates on Bitcoin, it will be the first soft fork to be implemented on the Bitcoin network since Segwit in summer of 2017. Much of the intervening time has been spent defining and implementing Taproot, as well as subjecting it to peer review and quality assurance processes unlike any upgrade to a cryptocurrency project. For example, Bitcoin Optech put together a series of workshops, attended by over a hundred participants throughout the Bitcoin space, to work through the technical details of Taproot and how to develop wallet code against it. This means that even though Taproot is technically much narrower than Segwit, the deployment process was much heavier.

On Elements, we were able to implement much of Taproot by simply syncing the software with Bitcoin Core, which it is based on. However, there were several technical challenges beyond this. In particular, we needed to define a new error correction code, blech32m, to handle Elements’ Confidential Addresses, which are longer than Bitcoin addresses and cannot be adequately covered by Bitcoin’s new bech32m code. Also, we had to define a new signature hash, which is the format for transaction data covered by the Schnorr signatures within Taproot transactions.

In Bitcoin, the Taproot signature hash included several improvements to the original Segwit signature hash (which in turn was a massive improvement over the legacy signature hash it succeeded). These improvements allowed verifiers to cache more data between signatures in the same transaction, and also allowed hardware wallets to directly understand more data about the inputs that they are signing, allowing them to verify fee rates and other quantities without access to historic blockchain data.

In Elements, all of these improvements apply directly, but because we have new transaction types: peg ins, peg outs and asset issuances, we also need to consider the issues of caching efficiency and hardware wallet visibility for these extra types of data.

Another aspect of Elements that differs from Bitcoin is that we have two applications of signatures: signed transactions, like in Bitcoin, and also signed blocks. This introduces a new area of design space not present in Bitcoin. For our initial Taproot deployment, which is happening concurrently with our “Dynamic Federations” update to block headers, we will only activate Taproot for transactions.

Next Steps

If all goes smoothly both Bitcoin and Liquid (which is based on the Elements Core software) will activate Taproot in the middle of November. Wallet developers on both blockchains have been hard at work implementing support; in the Bitcoin Core wallet, a new descriptor type has been defined for Taproot spends, and on the Elements side, all output descriptors need to be extended to support Confidential Assets. Meanwhile, the PSBT wallet communication protocol has been updated for Bitcoin wallets to exchange Taproot-related data, and we overhauled Elements’ PSET for the same purpose. We will cover this in our next blog post.

Aside from wallet support, there are several exciting things in the pipeline for Elements. As mentioned, we plan to implement Taproot support in Elements blockheaders in a future version of Elements. In parallel to that, we plan to use Taproot’s new “tapleaf” script versioning scheme to implement Simplicity, our upcoming blockchain programming language. The use of tapleaf versioning means that just as users may hide their use of Script in cases that they don’t need its power, users can also hide their use of Simplicity when it is not needed. This allows them to “patch” the expressivity gaps in Script using Simplicity exactly when it’s needed, and retain the privacy and efficiency of Script when it is not.

Finally, the Schnorr signatures present in Taproot open a wide range of new protocols based on scriptless scripts. This could mean that users can move Bitcoin onto and off of Liquid using swap transactions on each chain that leave no trace that they are related; similarly, they could exchange L-BTC for another Confidential Transaction-enabled currencies, without revealing the transaction amounts on either blockchain. Closer to home, we are continuing to push forward on our Musig2 protocol for multisignature transactions on a single blockchain, and on extending this protocol to threshold signatures and other advanced protocols.

Note: This blog was originally posted at https://medium.com/p/a44b060904cf