What are Schnorr signatures? What is tap root?

Taproot offers its own version of the Merkle tree, called the script tree. Members can choose to spend using:

• public key as a regular signature;
• spending with a script.

In the first case, this is the default spending path, where single or multi-party public keys are indistinguishable.

In the second case, hidden scripts are not revealed until the spending is made. Different scripts can be organized into a Merkle tree, and outputs can also be spent by expanding one of the specifiers.

If we spend a transaction with a primary spend script, we simply provide a Merkle proof that consists of the primary spend script and a hash of the alternate spend script – this is enough to confirm that the primary spend script is contained in the script tree.

Taproot uses the MAST structure to hide the conditions behind the merkle root. The Merkle root itself is hidden in this scenario and allows direct spending through the key. Only a single key is sent to the blockchain – no one sees that there are additional conditions.

In combination with Schnorr signatures, the MAST structure is hidden thanks to Taproot outputs. At the top of the Merkle tree, there is an option to publish a single public key and signature. As a result, P2PKH and P2SH transactions look identical.

An illustration is the closing of the Lightning channel.

Lightning channels are variations on 2-of-2 multi-signatures. Instead of closing the transaction with a cumbersome script, Schnorr allows signatures to be combined and presented as Taproot’s public key/signature. When both parties agree, the result looks like someone used up that output with a regular signature, sending it to two addresses. An observer will not be able to determine that this is a Lightning channel.

TapBranch is a script tree (TapTree) for closing a Lightning channel

To hide the MAST structure, the TapBranch hash in the graph above is hashed with an aggregated public key (thanks to the Schnorr scheme, Alice and Bob can add their public keys to create an internal Taproot key).

The resulting hash is used as a private key, from which another modified public key is derived. Changing keys, also known as hiding a key pair, involves inlining scripts 1 and 2.

The modified public key is then added to the Taproot internal key to create the Taproot exit key. The process is illustrated below:

As mentioned, there are two spending keys. The default spending path is when Alice and Bob agree to close the Lightning channel, and the Taproot exit key ensures that the transaction looks like a standard P2PKH transaction. In other scenarios, the script used is revealed once the coins are spent, while all other options remain hidden.

In the example above, if Alice and Bob agree to make a Lightning payment, they can jointly merge Schnorr signatures, create a master public key, add signatures together, and create a master signature.

Both parties sign partial signatures with their individual keys, and closing the Lightning channel looks like a direct payment to the public key.

In the case where the closure is inconsistent, only the script in use is expanded. Verifiers will be able to determine that the Threshold Public Key has been changed via the Merkle Root. However, all other options/scripts will remain hidden.

The graph above shows that the script tree offers a new recovery option for accessing bitcoins. Taproot provides a recovery option for lost coins (for users with upgraded wallets). If a single key is lost, it is lost forever. If the user loses the private key and their funds are in the Taproot exit form, then there must be another way by which to claim the coins (for example, recover 3-of-5 backup keys held by the user’s relatives).

Taproot enhances the privacy, efficiency, and flexibility of Bitcoin scripts by allowing developers to write complex scripts while minimizing impact on the blockchain.

Complicated transactions allow you to significantly save on fees, since scripts that require processing a lot of data no longer have to pay fees that exceed the fees in a standard Pay-to-Public-Key-Hash transaction. The more complex the transactions, the higher their efficiency.

Because Taproot allows complex transactions with just one signature, the number of bytes used for aggregated keys and signatures does not change based on the number of signers. When using the Witness-Script-Hash (P2WSH) multi-signature, each additional public key adds 8.5 bytes, and each additional signature adds approximately 18.25 bytes.

From a privacy point of view, Taproot allows you to minimize information about the conditions of spending for the exit of a transaction, which is disclosed in the blockchain. With Taproot, most apps can use the spending path based on a key that is kept private.

While the Schnorr scheme allows multisignature transactions to appear to be normal Pay-to-Public-Key-Hash transactions, Taproot expands the range of transactions that can be given this appearance (make Pay-to-Public-Key-Hash and Pay-to-Script-Hash indistinguishable). ).

Subscribe to the CryptoNewsHerald channel at YouTube!