↓Skip to main content
  1. Posts/

Taproot Soft-Fork: What Does it Bring to Bitcoin?

·6 mins
Ixonae
Crypto Currencies
Ixonae
Author
Ixonae
Table of Contents

The Taproot soft fork was finally enabled on Sunday 14th with block 709,634. This is the first major update to Bitcoin since SegWit in 2017. Its implementation was decided in June this year (at block 687,284) when 90% of the mined blocks signalled their support for the update over a period of two weeks (to be more accurate, the requirement was to have 1,815 out of 2,016 blocks supporting the update.)

Taproot ships three Bitcoin Improvement Proposals (BIP340, BIP341, and BIP342) including Schnorr signatures, MAST, and Tapscript. In this article, we will go through all of them and see how they work and what they bring to Bitcoin. Note that the changes allow backward compatibility (meaning that you will still be able to use old address types.)

Schnorr Signatures
#

Until now, Bitcoin used ECDSA signatures (secp256k1 curves) with SHA256 hashes to authenticate transactions. The BIP 340 introduces a new way to do signatures using Schnorr. The new mechanism also uses elliptic curve cryptography, but its main advantage is the support of native multisig.

In the current settings, a transaction coming from a multisig address will have multiple signatures attached. However, since Schnorr is linear, it allows to aggregate multiple signatures into a single one (“key aggregation”). This offers the following benefits:

  • Multisig transactions will always have a single signature of the same size, regardless of the number of participants, which offers performance improvements (only one signature to check vs multiple ones, and Schnorr is faster than ECDSA.) This also offers a network capacity gain since their size will be smaller.
  • With Schnorr, it is not possible to know if an address is multisig or not, and how many participants took part in it as long as everybody signs the transactions

Let’s see more in detail how things would work out in real conditions with a legacy 3/3 P2SH address. The left part of the schema shows the address creation process and the right one shows how to spend funds sent to this address.

The old way of creating a 3/3 multisig address and of spending the funds

The previous schema shouldn’t be a surprise if you are familiar with Bitcoin; we observe that when the funds are spent it is possible to see that the script required the signatures A, B, and C (the three expected keys would be revealed even if the address was a 2/3 multisig.)

Now, let’s look at how things would work with Taproot addresses. As before, the left part of the schema shows the address creation, and the right part how to spend funds with it.

Creating a 3/3 multisig address and spending the funds

In this case, the only thing that will be present on the blockchain is the aggregated signature matching the public key generated in the first step. Therefore, it will not be possible to know by looking at the transaction that the funds were stored in a multisig address. In the case where the address was allowing 2/3 signatures, things would also be slightly different and we will discuss this more in detail later as well.

Merkle Branch
#

The BIP 341 introduces MAST (Merkelized Abstract Syntax Tree) as a way to do pay to script transactions. Previously, the completed script would have to be shared to be able to spend funds sent to a P2SH address. With the new approach, only the part of the script which is actually used is made public. This has two advantages: it requires less space on the blockchain and it enhances the privacy of the entities taking part in the transactions. Let’s have a look at the following schema as an example. It shows a script involving four public keys (1, 2, 3, and 4) that allows sending money either with two signatures by the keys 1, 2, or 3, or by a single signature of the key 4 if the current block is more than x.

Example of a MAST script

Let’s say that we want to send some funds using keys 1 and 2. In this case, we will sign the transaction with the private keys 1 and 2, and then reveal script 1 and the elements in green. Doing so, the conditions for script 1 are fulfilled, and the root hash (which was used when creating the address) can be re-computed, therefore proving that script 1 is allowed to be used to spend funds.

P2TR (Pay-To-Taproot)
#

In order to support the previous changes, BIP341 introduces SegWit version 1 spending rules (2017’s SegWit was version 0) as well as the new Pay-To-Taproot address type (P2TR.) These addresses will begin by bc1q instead of bc1q.

One of the advantages of P2TR is that it can be used for paying to a script or to a public key, and it will not be possible to say which of the two an address is until funds where spent. Actually, even after that, it may not be possible to know if there was a script as there is an option that allows all parties involved in a smart contract to sign a transaction rather than following the rules of the script.

Tapscript
#

Tapscript - enabled by the BIP342 - is the final part of the Taproot update and includes improvements to the script structure to accommodate the other changes. Among other things, BIP342 does the following:

  • Change OP_CHECKSIG and OP_CHECKSIGVERIFY to be usable with Schnorr signatures
  • OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled and replaced by OP_CHECKSIGADD
  • The maximum script size of 10,000 bytes does not apply anymore, and the size is just limited the block weight limit

In addition, to make future scripts improvements easier, Tapscript includes new opcodes (transaction instructions) that can be used to add features. The codes are numbered 80, 98, 126-129, 131-134, 137-138, 141-142, 149-153, 187-254, and if any of them are encountered at the moment, the validation will succeed and ignore the other rules. The opcodes are named as OP_SUCCESSx (e.g., OP_SUCCCESS80, OP_SUCCESS98, …, OP_SUCCESS254)

P2TR Support
#

Bitcoin.it has a list of the major Bitcoin wallets and services and which type of addresses they can receive funds to. So far, it seems that most of them did not share any dated plan to implement P2TR addresses. Notably, Trezor plans to implement it by December this year.

Sources
#

Credits
#