Bitcoin Taproot Upgrade: A Brief Review

It was Bitcoin's long-awaited major upgrade since 2017. Finally, on November 14, 2021, Taproot, the highly anticipated upgrade, was officially activated on the Bitcoin blockchain at block height 709,632.

In this article, Zondax's in-house engineer will provide a brief technical review of Taproot and demonstrate its use case.

Included in the upgrade release are 3 BIPs (Bitcoin Improvement Proposition):

• Schnorr Signatures for secp256k1 (BIP 340)
• Taproot: SegWit version 1 spending rules (BIP 341)
• Validation of Taproot Scripts (BIP 342)

But why did Bitcoin decide to activate the privacy-focused Bitcoin Taproot upgrade exactly? And what could be the benefits? As stated in the release note from Bitcoin.org,

“If activated, these improvements will allow users of single-signature scripts, multisignature scripts, and complex contracts to all use identical-appearing commitments that enhance their privacy and the fungibility of all bitcoins. Spenders will enjoy lower fees and the ability to resolve many multisig scripts and complex contracts with the same efficiency, low fees, and large anonymity set as single-sig users.”

Taproot has been discussed for a long time in the Bitcoin community. The first reference was MAST (Merklized Abstract Syntax Trees) back in 2013. MAST is an extension of the Merkle Tree - a concept which Bitcoin already use to prove the inclusion of blockchain data more efficiently and securely - but MAST is applied to advanced transaction types or conditional payments. Since the application has evolved and the abstract syntax trees have been dropped, despite the acronym MAST remaining unchanged, it is now proposed to refer to Merklized Alternative Script Trees instead.

Merkle Tree

A Merkle Tree allows efficient and secure verification of the contents of a large data structure. It uses cryptographic hash functions. Each node is a hash of the 2 precedents nodes (or child nodes) concatenated, except for the leaf, which is the hash of the data block.

The Top Hash is frequently referred has the Merkle Root in Bitcoin literature. The merkle root is stored in the block header. Each block also stores the hash of the previous block's header, chaining the blocks together. Such design ensured a transaction can not be modified without modifying the block that records it and all following blocks. Once the transactions data is received, the program calculates the merkle root and verifies it matches the one in the header for which the transaction is requested.

Script in Bitcoin

Another critical concept in Bitcoin is its language: Script, a simple, stack-based, and processed from left to right language. It allows building a predicate that will tell if you can spend your bitcoins or not. It is intentionally not Turing-complete, with no loops. Instructions are called opcodes: OP_TRUE, OP_IF, OP_RETURN, ...

Bitcoin is what we call UTXO based (Unspent Transaction Output), and each utxo has a spending condition and a value. Zondax will share more insights regarding UTXO based blockchain in our next blog post.

In this example, we have a Pay-To-Pubkey-Hash script (P2PKH), which allows a basic bitcoin transfer for which we need to give a valid signature and a public key that would match the public key hash.

Taproot

Using those two familiar concepts, it is possible to deconstruct a complex script in several smaller parts and put it in a merkle tree.

With Taproot, developers aim to have several conditions that could be useful in a multisig transaction with fallback conditions. With each fallback conditions being hashed and only revealed when spending the transaction, it also improves privacy. People simply looking at the blockchain cannot know the other conditions. Public key aggregation is also made possible via the schnorr signature scheme.

The schnorr signature is helpful in the case we have 2 out of 2 multisig condition. It means the two participants has to sign the transaction. We can then transform those two signatures into one. It saves precious block space.

Only the merkle root of the merkle tree build with all the conditions will be published on the blockchain, similar to the block header only contains the merkle root of all the transactions of a specific block. This is what makes it private as hashing function are not reversible.

On the other hand, the scripts will need to be saved by the users with their private key. Indeed, the private key won't be enough to sign in case of more advanced script conditions. It also adds a bit more bits to basic transactions and therefore takes a bit more space in a block.

Lightning network use case

Let's consider a basic Hash TimeLock Contract (HTLC) similar to those used in Lightning Network. This contract can terminate three ways:

1. Alice receives the contracted money (a payment) by publishing a pre-image that releases the contract's hashlock.
2. Bob receives the contracted money (a refund) after a timelock has expired.
3. Alice and Bob mutually agree on how to distribute the money, usually because one of them could use one of the preceding conditions to force payment or refund.

The two first conditions are fallback conditions in case Alice or Bob misbehave and won’t cooperate. Those conditions can be put in a merkle tree.

The third condition is a signature build with Alice and Bob keys which can be aggregated into a schnorr signature. It is also consider the default spending path.

The taproot output key is what will be used to get the taproot address. You will need to integrate in the following template:

The 1 stand for segregated witness version 1. Its op code is the hex value 51 we also need to specify the size of the key which is 20 in hex so 32 bytes. When encoding the public key we use the compressed key and we only choose public key with even Y value coordinate. So in a compressed format the hex encoding always start with 02 . In order to save space we can remove this first byte as its value is implicitly known.

Conclusion

As Bitcoin previously described, “Taproot and schnorr also include efficiency improvements for full nodes such as the ability to batch signature verification. Together, the improvements lay the groundwork for future potential upgrades that may improve efficiency, privacy, and fungibility further.” In other words, Taproot adoption will improve privacy and allow more complex transactions. Something that can only be possible since the patent on schnorr scheme has ended.

In the other hand, wallets must do the heavy lifting by including this important upgrade in their code base. They must include a new cryptographic signature scheme and creating simple transaction has become a bit more complex.

At Zondax, we have already been working on this questions and implemented secure solutions for our clients.