first level title

What is Taproot?

Taproot was first proposed in 2018 by Bitcoin Core contributor Gregory Maxwell. This implementation is currently under development. Without Taproot, these complex transactions (timelocks, multi-signatures) would require multiple transactions to complete and thus fail easily.

Taproot enhances the privacy of Bitcoin by allowing complex transactions (multi-signatures, timelocks) to be executed as if they were a single Bitcoin transaction.

The Taproot upgrade includes three important technical changes (concepts) to enhance Bitcoin's scalability, privacy, and flexibility.

• Schnorr signature

• MAST

• Schnorr signature

first level title

P2SH（Pay-to-ScriptHash）

A Bitcoin address is a string of letters and numbers. Users can share it with others in order to receive BTC from the latter. There are two main standards for Bitcoin transactions: Pay-to-PubKeyHash (P2PKH) and Pay-to-ScriptHash (P2SH).

Before discussing the two concepts of P2SH (Pay To Script Hash) and P2PKH (Pay-To-PubKey Hash), let's get familiar with the background knowledge about Bitcoin:

• On the Bitcoin network, Bitcoins are in the form of UTXOs. UTXO is the abbreviation of Unspent Transaction (TX) Output (unspent transaction output), that is, a unit of variable denomination formed after the execution of a Bitcoin transaction. For example, you have 10 BTC in your Bitcoin wallet and you want to transfer 5 BTC to a friend. The Bitcoin blockchain is handled differently. It will spend all 10 BTC (full balance), transfer 5 BTC to your friend's wallet, and transfer the remaining 5 BTC (10 BTC - 5 BTC = 5 BTC) to your own wallet. Now, you and your friend each hold unspent 5 BTC.

• Bitcoin uses scripts (a few lines of code) to specify the conditions for spending BTC/UTXO. Scripts are used as a locking mechanism.

• BTC locked in script. When the script returns success (i.e. the condition is met), the BTC is unlocked.

• Anyone can send BTC to any Bitcoin address. Only when certain conditions defined in the script are met, the locked BTC can be spent. The script determines how the recipient can spend the received BTC. When initiating a transaction, the sender will put in a transaction called"PubKey Script (aka Lock Script)"script. The recipient (when spending later) needs to generate a"Signature Script (aka Unlock Script)", which is a collection of data parameters that satisfy the PubKey script. The signature script is also called "scriptSig" in the code.

• first level title

Pay-to-PubKeyHash (P2PKH)

Pay-to-PubKeyHash is a traditional Bitcoin address format. Its address starts with the number 1.

Only the owner of the P2PKH address can unlock the PubKey script and spend the received BTC by providing the public key hash and private key signature. The private key is used to prove ownership of the public key hash.

As we discussed above, scripts define under what conditions BTC on a particular address can be spent. When the specified conditions are met and verified by the network, the BTC on that address will be unlocked for spending.

How does this process work? —— The receiver first generates a PubKey script and shares it with the sender. The sender adds this PubKey script to the transaction when sending BTC. When receiving BTC, if the recipient wants to unlock these BTC UTXOs, they must provide the public key hash and private key signature, and meet the conditions mentioned in the PubKey script.

For example, these conditions could be:

• Unlocking BTC requires at least two signatures.

• Provide a password (password) to unlock.

• It takes a while for BTC to unlock.

The above situations can be used as the conditions for unlocking BTC.

When sending bitcoins, the sender needs to include in the transactionPubKey script. Therefore, this increases the volume of the transaction, generating transaction fees that are about 5 times higher than normal transactions.

first level title

Pay-to-ScriptHash (P2SH)

Pay To Script Hash (P2SH) can help the sender avoid the extra cost and shift this responsibility (additional cost) to the receiver who really needs to use the conditions specified in the locking script. Pay-to-ScriptHash Bitcoin addresses start with the number 3.

Under this transaction standard, senders do not need to put long PubKey scripts into their transactions. Here, the lock script is replaced with the hash of the redeem script. The redemption script hash value is calculated by the redemption script. Redeem scripts are similar to PubKey scripts and contain conditions that must be met by the receiver before spending unspent outputs. The sender only needs to indicate the hash of the redemption script in the transaction. The redeem script hash can be translated into standard Bitcoin addresses, and the sender can send BTC to these addresses without any special action or additional fees.

When the receiver wants to unlock the BTC on this P2SH address, he needs to generate a redemption script with the same hash value and include it in the transaction. As a result, the size of the transaction used by the recipient to unlock the UTXO increases, as does the cost of executing the transaction.

For example, Alice wants to send 10 BTC to Bob. Alice must include the redeem script hash into the transaction. First, Mr. Bob generates a redemption script, and then sends the hash value of the redemption script to Alice, so that Alice can add the hash to the transaction and initiate the transaction. If Bob wants to spend this UTXO, he must generate an unlocking script with the same hash value and meet the conditions mentioned in the script.

text

Advantages of Pay-to-ScriptHash

• Use hashes instead of lengthy scripts.

• The sender can put any number of redemption script hashes in the transaction without knowing the spending conditions specified in the script.

• first level title

（……）

MAST (Merkle Abstract Syntax Tree)

MAST isMerklized Abstract Syntax Tree (Merkel Abstract Syntax Tree)abbreviation of.

Why use MAST? If you want to spend BTC from a P2SH address, you must generate a redeem script with the same hash and include it in the transaction. If there are too many spending conditions stipulated in the script, the transaction volume will become extremely large. MAST can solve this problem very well.

Merkle abstract syntax tree is a combination of Merkle tree and abstract syntax tree.

Just like Pay To Script Hash (P2SH) pays to a script with a hash of X, MAST pays to a Merkle root with a hash of X. MAST is to assemble each condition in a large set of conditions into a hash tree (the so-called Merkle tree), and the root value of the Merkle tree is a hash value, which is hashed by all the conditions.

How are Merkle roots and hash trees generated?

First perform hash calculations on all scripts (conditions); then combine the calculated hash values ​​with adjacent hash values ​​for hash calculation to generate a new set of hash values. Repeat this two-by-two hash calculation process until the last hash value is calculated. This hash is the Merkle root.

Suppose there are four sets of conditions. First, calculate the hash values ​​of these four groups of conditions separately; then pair these four hash values ​​in pairs to calculate two hash values; finally, combine these two hash values ​​for hash calculation, Generate the final hash value. This final hash is the Merkle root.

This Merkle root can be translated into a valid Bitcoin address capable of receiving payments, i.e., the defaultMerklized Bitcoin address. Merkle Bitcoin addresses have many advantages, the main advantage is that it is not necessary to know all script units to verify whether a script is located on this Merkle tree. This technique is calledMerkle Proof, which can be used to easily verify that a Bitcoin UTXO contains certain unlocking conditions.

Schnorr signature

Schnorr signature

In cryptography, a Schnorr signature is a digital signature generated by the Schnorr signature algorithm proposed by Claus Schnorr. The Schnorr signature algorithm is a digital signature scheme known for its simplicity, which optimizes the verification and authentication process by aggregating multiple signatures into a single signature. This scheme is suitable for multi-signature transactions.

In order to execute a transaction, you need to sign the transaction with your private key, proving that you are the owner of the BTC behind a certain public key. However, to perform a multi-signature transaction, you must provide multiple signatures. These signatures take up additional space.

Schnorr signatureSchnorr signatureJust happens to solve this problem.

To understand Schnorr signatures, let's look at two examples:

• （……）

• Another case is a multi-sig transaction. Suppose you need 100 signatures and the size of each signature is 5 bytes, the Schnorr signature scheme can combine these 100 signatures into a Schnorr signature with a size of 64 bytes. Saving 436 bytes (5*100-64=436) of memory can be used to store more transactions. (Note: The current elliptic curve signature can be more than 5 bytes)

first level title

Bitcoin Taproot: Summary

This article mainly introduces Taproot around the following points:

• Taproot is a Bitcoin upgrade proposal proposed in 2018 by Bitcoin Core contributor Gregory Maxwell.

• Taproot makes complex transactions such as multi-signature transactions and time-lock transactions look like ordinary Bitcoin transactions, enhancing the privacy of Bitcoin.

• The Taproot upgrade mainly includes 3 technical concepts - P2SH, MAST and Schnorr signatures.

• Bitcoin uses scripts to indicate the conditions for spending BTC/UTXO (unspent transaction output).

• Pay To Script Hash (P2SH) can help the sender avoid the additional transaction fee and shift this responsibility (additional transaction fee) to the receiver who really needs to use the conditions stipulated in the locking script.

• Using MAST, bitcoins can be locked using a Merkle Abstract Syntax Tree. The Merkle tree (corresponding to the Merkle root) determines all the complex conditions under which unspent BTC can be unlocked. Merklized Abstract Syntax Trees (MAST) is proposed to be introduced into the Bitcoin blockchain to reduce the size of BTC transactions, so that the receiver does not need to attach lengthy scripts to the transaction. Using only the Merkle root it is possible to verify that the receiver-generated script belongs to the original set of conditions.

• Original link:

Original link:

https://b10c.me/blog/004-the-incomplete-history-of-bitcoin-development/

Author: 0xB10C