The original title: "dry | COINS to upgrade proposal Taproot interpretation technology"
This article will discuss the bitcoin upgrade proposal.Taproot The proposal will introduce many new features. This article will analyze Taproot from a technical perspective, introduce the technologies involved in this upgrade, and what benefits these technologies will bring to bitcoin users.
Taproot by Bitcoin Core contributor & NBSP; Gregory Maxwell It was first proposed in 2018. This implementation is currently under development. Without Taproot, these complex transactions (time locking, multi-checkout) require multiple transactions to complete and are therefore vulnerable to failure.
"Taproot enhances bitcoin's privacy by enabling complex transactions (multiple signatures, time locks) to be executed like single Bitcoin transactions."
The Taproot upgrade includes three important technical changes (concepts) designed to enhance bitcoin's scalability, privacy, and flexibility.
· P2SH (P2SH is not part of the Taproot upgrade, but it will help you understand why Taproot is upgraded)
We'll discuss these three concepts at a technical level to see how the Taproot upgrade will benefit bitcoin users.
A Bitcoin address is a string of letters and numbers. Users can share it with others in order to receive BTC from them. There are two main standards for bitcoin transactions: pay-to-PubkeyHash (P2PKH) and pay-to-scripthash (P2SH).
Before we discuss the concepts of P2SH (Pay To Script Hash) and P2PKH (pay-to-Pubkey Hash), let's get some background on Bitcoin:
· In the Bitcoin network, bitcoin is in the form of UTXO. UTXO is & have spent Short for Unspent Transaction (TX) Output, which is a unit of variable denomination formed after a Bitcoin Transaction is executed. For example, say 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 spends 10 BTC (the whole balance), transfers 5 BTC to your friend's wallet, and transfers 5 BTC (10 BTC-5 BTC = 5 BTC) to your own wallet. So you and your friend each have 5 BTC that they didn't spend.
· Bitcoin uses a script (a few lines of code) to dictate the conditions under which BTC/UTXO is spent. Scripts are used as a locking mechanism.
· BTC locked in the script. When the script returns success (that is, the condition is met), BTC is unlocked.
· Anyone can send BTC to any Bitcoin address. The locked BTC can only be spent if certain conditions defined in the script are met. The script determines how the recipient can spend the received BTC. To initiate a transaction, the sender places a Script called a "PubKey Script" in the transaction. The recipient (at a later cost) needs to generate a "signature script (aka unlock script)," which is a collection of data parameters that satisfy the PubKey script. Signed scripts are also called "scriptSig" in code.
In the example above, when you send 5 BTC to a friend, the lock script is also included in the transaction. If your friend wants to spend these BTCS, he must generate an unlock script that meets the conditions specified in the lock script.
Pay-to-pubkeyhash is a traditional Bitcoin address format. The address begins with the number 1.
Only the owner of the P2PKH address can unlock the PubKey script and spend the BTC received by providing the public key hash and private key signature. The private key is used to prove ownership of the public key hash value.
As we discussed above, scripts define under what conditions BTC can be spent at a particular address. When specified conditions are met and network authentication is passed, the BTC at that address is unlocked for spending.
How does the process work? The recipient first generates the PubKey script and shares it with the sender. The sender adds the PubKey script to the transaction when it sends the BTC. When receiving a BTC, if the recipient wants to unlock these BTC UTXOs, it provides a public key hash and a private key signature, and meets the conditions mentioned in the PubKey script.
For example, these conditions could be:
· At least two signatures are required to unlock BTC.
· Provide the password (password) to unlock.
· BTC needs to wait for some time to unlock.
These conditions can be used to unlock the BTC.
To send bitcoin, the sender needs to include it in the transaction. PubKey script. As a result, this increases the volume of the transaction, generating transaction fees that are about five times higher than normal transactions.
Here, the sender must bear the additional cost. Pay-to-scripthash can help senders avoid this extra cost.
Pay To Script Hash (P2SH) can help the sender avoid additional costs and shift this responsibility (additional costs) To the recipient who actually needs To use the conditions specified in the lock Script. Pay-to-scripthash Bitcoin addresses begin 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 a Redeem script hash. The redemption script hash value is calculated from the redemption script. A redemption script is similar to a PubKey script in that it contains conditions that must be met by the recipient before spending is output. The sender simply indicates the hash value of the redemption script in the transaction. Redemption script hashes can be translated into standard Bitcoin addresses to which the sender can send the BTC without doing any special operations or paying extra.
When the receiver wants to unlock the BTC on this P2SH address, it needs to generate a redemption script with the same hash value and include it in the transaction. As a result, the transaction size 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 redemption script hash in the transaction. First, Mr. Bob forms 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 the UTXO, he must generate an unlock script with the same hash value and satisfy the conditions mentioned in the script.
Remember, Alice only adds the hash value of the redemption script to the transaction, not the entire script. Therefore, Alice does not incur additional costs.
· Use hashes instead of lengthy scripts.
· The sender can put any number of redemption script hashes into the transaction without knowing the cost conditions specified in the script.
· Reduced the transaction fee burden of the sender.
MAST stands for Merklized Abstract Syntax Tree.
Why use MAST? If you want to spend BTC in the P2SH address, you must generate a redemption script with the same hash value and include it in the transaction. If the cost conditions specified in the script are too high, the transaction volume becomes extremely large. MAST is a great way to solve this problem.
Merkle abstract syntax tree is a combination of Merkle tree and abstract syntax tree.
Just as Pay To Script Hash (P2SH) pays for scripts with a Hash of xyz, MAST pays for merkelroot with a Hash of xyz. MAST is a hash tree (merkle tree) that combines elements from a large set of conditions. The merkle tree's root value is a hash of all the conditions.
First, hash all scripts (conditions) separately. The calculated hash value is then combined with adjacent hash values for hash calculation to generate a new set of hash values. Repeat the two-by-two hash calculation until the last hash value is calculated. This hash value is the Merkelian root.
Suppose there are four sets of conditions. Firstly, the hash values of these four groups of conditions are calculated respectively. Then you pair these four hashes, and you compute two hashes; Finally, the two hashes are combined to produce the final hash. The last hash is the Merkeln.
This Merkelroot can be translated into a valid Bitcoin address that can receive payments, i.e., Merklized Bitcoin Address. The Merkle bitcoin address has many advantages, but the main advantage is that you can verify that a script is on the Merkle tree without knowing all the script units. The technique, called Merkle Proof, can be used to easily verify that a Bitcoin UTXO contains certain unlocking conditions.
In MAST, BTC is bound to a Merkle tree. This Merkle tree specifies all the complex conditions that can unlock BTC without cost. Each leaf represents a condition. To understand the lock BTC, you must generate a script that meets the criteria represented by a branch of the Merkle tree. Using merkle roots alone, you can verify that the condition belongs to the original set of conditions (that is, verify that a leaf node is on the Merkle tree). Once the Bitcoin blockchain network discovers that a script (and the condition it represents) belongs to the Merkelian root, the network knows that the script is a lock condition for those bitcoins and begins validating the unlock script. Therefore, we can spend BTC locked with MAST without having to generate the full script and include it in the transaction. This helps reduce the volume of BTC transactions.
In cryptography, Schnorr signature is a digital signature generated by Schnorr signature algorithm proposed by Claus Schnorr. Schnorr signature algorithm is a digital signature scheme known for its simplicity, which aggregates multiple signatures into a single signature to optimize the verification and authentication process. The scheme is suitable for multiple contracts.
To execute a transaction, you need to sign the transaction with a private key to prove that you are the owner of the BTC behind a public key. However, to execute a multi-signed transaction, you must provide multiple signatures. These signatures take up extra space.
Take 12/20 trades for example. 12/20 means that at least 12 of the 20 signatures are required to execute the transaction. When a transaction is signed, the signature is also stored in the block. Assuming that the size of one signature is 5 bytes, 12 signatures occupy 60 bytes of memory (5*12 = 60), and 100 signatures occupy 500 bytes of memory. This increases memory usage. The Schnorr signature solves this problem.
Suppose you need 100 signatures and each signature is 5 bytes in size, the Schnorr signature scheme can combine these 100 signatures into a single Schnorr signature of 64 bytes in size. The 436 bytes of memory saved (5*100-64=436) can be used to store more transactions. (Note: Elliptic curve signatures are now longer than 5 bytes.)
Bitcoin UpgradeTaproot plans to introduce these concepts into the Bitcoin blockchain to enhance its scalability, privacy and flexibility.
This article mainly introduces Taproot around the following points:
· Taproot is a Bitcoin upgrade proposal proposed by Bitcoin Core contributor Gregory Maxwell in 2018.
· Taproot enhances the privacy of Bitcoin by making complex transactions such as multi-signature transactions and time-locked transactions look like ordinary Bitcoin transactions.
· The Taproot upgrade consists of three main technical concepts -- P2SH, MAST, and Schnorr signatures.
· Bitcoin uses scripts to indicate the conditions under which BTC/UTXO (no transaction output is spent) is spent.
· Pay To Script Hash (P2SH) helps the sender avoid additional transaction fees and shifts this responsibility (additional transaction fees) To the recipient who actually needs To use the conditions specified in the lock Script.
· Using MAST, bitcoin can be locked by merkle tree abstract syntax tree. The Merkle tree (the counterpart of merkle root) determines that all complex conditions that do not cost BTC can be unlocked. Merklized Abstract Syntax Trees (MAST) were proposed to be introduced into the Bitcoin blockchain to reduce the volume of BTC transactions and eliminate the need for recipients to attach lengthy scripts to transactions. The Merkle root alone is used to verify that the script generated by the recipient belongs to the original set of conditions.
· Schnorr signature can combine multiple signatures into a single signature.