Interpreting bitcoin scalability solutions: Witness to isolation
The original title: "dry goods | detailed explain isolation witness"
Author: Magomed Aliev
Ah Jian is a fan of Ethereum
For example, there's a scenario that says,Lightning network"; However, the conditions do not seem to be in place for a lightning network to be implemented within the Bitcoin network, because of some of bitcoin's own flaws. Another solution, 'Segregated Witness,' also focuses on scalability, but it also solves many problems, including flaws that needed to be fixed for the Lightning network implementation. In this article we will explain the advantages of isolated witnesses and how they work.
Segregated Witness (SegWit) is a soft described by multiple BIPs (141, 142, 143, 144 and 145)yThe main purpose is to optimize the structure of bitcoin transactions and blocks by moving transaction signatures (also known as "scriptSig", "Witness" or "unlock scripts") from transactions into a separate structure. Not only does it allow for a reduction in the size of bitcoin transactions (thus allowing more transactions to fit into a block), but it also addresses the issue of "transaction malleability" (the flaw we mentioned at the beginning that hindered the implementation of the Lightning network), It's critical for technologies like payment channels and The Lightning Network, which are based on bitcoin's transaction structure.
How does quarantine witness work
Before we get started
Let's start with a brief review of bitcoin's payment system. It is not, like a bank, a list of accounts and balances. Instead, each Bitcoin address's balance is represented by a series of transactions sent to that address; A major part of the transaction data structure is the input and output. The input is the prior transaction that we want to spend (to be precise, the input is not the entire transaction, but the output of a transaction, since we may transfer funds to multiple addresses in a single transaction), and the output of the transaction is the destination address to which our funds are sent. The chart below shows the structure of bitcoin transactions:
The PubKey Script field in the output (hereinafter referred to as "scriptPubKey") is what we call a "lock Script". It is used to ensure that only the owner receiving the address can use the payout. The Signature Script field (hereinafter referred to as "scriptSig") is also known as an "unlock Script" because it is the key used to unlock the lock Script and is used to prove address ownership.
Editor's note: Here's a GIF showing how the bitcoin stack works, but it's not available in the wechat tweet. I strongly recommend viewing it on the website.)
More details on bitcoin transactions and the lock script, unlock script features can be found here.
Backward compatibility
In fact, segregated witness not only changes the structure of the transaction, but also changes the output of the transaction. However, this is not to say that traditional type UTXO (unspent transaction output) and SegWit type UTXO cannot be spent in the same transaction: In this case, the traditional type UTXO will load the proof of ownership in the input (the script signature field), while the isolated witness type UTXO will load the proof in a structure other than the transaction input.
After all, the location of the isolated witness is a soft fork, and this upgrade should be negligible and not enforced, which means that unupgraded nodes should be able to handle the output of the isolated witness type. In fact, the old nodes andThe walletThese UTXOs will be assumed to be expended by anyone, meaning that these UTXOs are expended even with empty signatures, so the transaction is still valid even if no signature is seen in the transaction. The upgraded nodes and wallets will look for signatures in a special "Witness" field outside of the transaction entry.
case
Pay-to-Witness-Public-Key-Hash
Let's use an example to illustrate how isolated witnesses can change the data structure of a transaction. Start with the standard pay-to-public-key-hash (P2PKH) transaction type.
What we're interested in is the output, especially its "scriptPubKey" field (the lock script field). Let's start with a standard locking script:
The lock script after the witness is isolated looks like this:
As you can see, the output of the isolated witness is much simpler than the output of the traditional type: only two values are pushed onto the script execution stack. As we mentioned above, older versions of Bitcoin clients would think of the output as money dropped on the ground -- they could spend the output without providing a signature. However, the new client interprets the first number as a version number, while the second corresponds to a locking script (the Witness program). In reality, only the hash of a compressed public key can be used here. We'll come to that later.
Now let's look at what happens when this output is consumed. The output of a traditional transaction has the following data structure at cost:
However, when spending an isolated witness output, the scriptSig of the transaction will be empty and all signatures will be placed in a special place:
warning
Although traditional client can process isolation to witness the deal (again, they will use this output as everyone can spend money), but they can't spend the money, the old type of purse may try to use empty signature to take to the testimony of a separate output, but the deal is invalid in reality (updated node will not allow this transaction on the chain). This means that the sender must know that the recipient's wallet does not support isolated witness in order to create the appropriate type of output for it.
As defined by BIP 143, the output of the isolated witness should be Compressed public key & NBSP; To create the hash value of. If you use a traditional type address or hash of an uncompressed public key, the output will become unavailable (your coins will lock up).
Pay-to-Witness-Script-Hash
Another key transaction type is P2SH. It allows transactions to be sent to the hash of the script (rather than the hash of the public key, which is the Bitcoin address). To cost the output of the P2SH transaction, the spender needs to provide a script (called a "redemption script") whose hash value should match the script hash value in UTXO and provide the signature/password/something else based on that script. This protects the unlock script from the sender of an address and saves space: for example, a multi-signature wallet lock script might be so long that we have to save the entire lock; With P2SH you can save only one hash.
Suppose you now have a multi-signature wallet that requires the signatures of two of the five private keys to use. If you use a traditional transaction, the lock script for the P2SH transaction output will look like this:
To spend it, the spender (who was also the recipient of the previous transaction) needs to provide a redemption script that defines the spending criteria (multiple signatures, 2-5), as well as two signatures. All of this goes into the transaction's input:
Take a look at the sender and receiver after using quarantined witness. The output lock script is as follows:
Just like the P2PKH transaction, the script for this output is much simpler. The first value represents the version number, and the second is the SHA256 hash (32 bits) corresponding to the redemption script (the Witness program). This function is used in part to distinguish the P2WPKH witness from the P2WSH witness by length (32-byte SHA256 hash vs. RIPpD160(SHA256(script))).
The transactions that use this output are as follows:
Embed the isolated witness in P2SH
We have seen the benefits of using isolated witnesses. However, the above example only works if both the sender and receiver have upgraded software. But that's not always the case. Consider this scenario:
Alice wants to transfer some BTC to Bob, who has wallet software that supports segregated witness and she doesn't. They can obviously only use the standard form of transactions, but Bob wants to use SegWit to reduce fees.
At this point, Bob can create a P2SH address that contains the SegWit script, and Alice will treat this address as a normal P2SH address, so you can directly transfer money to this address without any problems. But Bob can use this output using SegWit transactions and get a discount on the fees (we'll explain the new pricing of fees for SegWit transactions below).
This is how the two types of SegWit transactions, P2WSH and P2WPKH, are implemented within P2SH.
P2SH(P2WPKH)
To implement a P2WPKH transaction in a P2SH transaction, Bob needs to create a witness using his public key. Then hash and transcode the result into an address:
The first value is the version number, and the second value is the 20-byte public key hash. The script does the SHA256 hash and then RIPpD160 to get a 20-byte hash.
The HASH160 result of this P2WPKH witness program:
Convert to an address:
The output lock script sent to this address looks just like a normal P2SH script:
So when Bob spends the output, the transaction will be structured like this:
In the beginning, the redemption script we created (that is, the witness program) is hashed once, and if the result matches the hash value in the lock script, the script is executed and the program verifies the signatures placed in the Witness field.
P2SH(P2WSH)
The P2WSH script can also be implemented using P2SH. Let's consider the 2-5 multi-signature wallet example described above. All the steps are the same as P2SH(P2WPKH) :
First, create a witness:
The first value is the version number, and the second value is the 32-bit SHA256 hash that corresponds to our signing script. Then we take the HASH160 hash of the witness and turn it into a normal P2SH address. To use the output to this address, we need to publish the witness in the scriptSig field and provide the full multi-signed script in the Witeness field.
Benefits of segregated witness
After combing through the technical parts, we can understand the main advantages of the quarantine witness.
Trading fusibility vulnerability
One of the key issues SegWit addresses is the "fusibility" of bitcoin transactions, which is the problem caused by the fact that the ID of a Bitcoin transaction is a hash value. Let's go into detail.
In past Bitcoin transactions, the signature was placed in the input part of the transaction, and a third party could change the signature without invalidating the transaction. This allows third parties to change the ID of the transaction (that is, the hash of the transaction) without changing the "key" fields of the transaction (such as the amount of input, output, or transfer) at all. This way, the transaction is still valid and has the same meaning, but with another ID, this can be used to perform another kind of attack, such as a DoS attack.
SegWit solves this problem because all signatures are placed outside the transaction, so signature changes do not change the hash value of the transaction and therefore do not affect the ID of the transaction. Quarantined witness also introduces a special identifier called "wTXID" : it is the hash of the transaction and the entire Witness part, so if a transaction is propagated without any Witness data attached, the transaction ID (TXID) is equal to the WTXID.
This solution allows us to create a succession of unconfirmed transactions without worrying about any risk, which is very important for a protocol like the Lightning Network. Without addressing the issue of transaction fusibility, payment channel participants will not be able to quickly retrieve whether a counterparty has linked an outdated channel transaction, since transactions with the same content may appear under a completely different ID.
Network and storage expansion
Witness data tends to be the largest portion of transaction data. In transactions that use multi-signed scripts, Witness can account for up to 75% of the transaction data volume. Thanks to SegWit, the transfer of the signature becomes optional: this data needs to be requested only if the node wants to validate the transaction. SPV clients and nodes without SegWit support also do not need to download additional data, saving disk space.
The available block space expands, reducing transaction fees
SegWit type transactions are cheaper than previous types of transactions because it reduces the amount of Witness data that needs to be stored. To be precise, the concept of "Size" (data volume Size) is slightly different for SegWit type transactions. It introduces the concept of "virtual size" : all data placed in the Witness section is multiplied by 0.25 to calculate the size of the data, so that more transactions can be crammed into a block. Let's look at an example.
Suppose we have a traditional type of transaction with a data size of 200 bytes. So you can fit 5,000 of these transactions into a 1MB block. An equivalent SigWit transaction has 120 bytes placed in the Witness area, so its virtual size is 80 + 0.25 * 120 = 110 bytes, so the block can hold 9090 such transactions. If the uplink fee is 40 sats per byte, the transaction fee drops from 8, 000 sats to 4, 400 sats, almost a 50% discount. (A bitcoin is a billionth of a BTC.)
Script version
As you may have noticed, each lock script has 1 byte to indicate the version of the script. Use different version numbers to add or change functionality (syntax changes, new operators, and so on) in the form of soft forks.
Efficiency optimization of signature verification
Isolating witnesses also optimizes the efficiency of signature algorithms (CHECKSIG, CHECKMULTISIG, and so on). Before SegWit, the number of hash calculation is proportional to the square of the number of signatures, but with the isolated witness, the computational complexity of the algorithm is reduced to O(n) (proportional to the number of signatures).
So what's the problem?
If there's no harm in it, why would anyone think there's a problem? There are many in the Bitcoin community who oppose this upgrade because, for all its strengths, it also has some downsides. Let's look at some of the ideas put forward by the opposing side.
Because SegWit is a soft fork, many clients may not upgrade, so both types of UTXO exist in the network simultaneously; Major changes such as the elimination of transaction ID fashability and a linear increase in hash times are not effective for non-SegWit output, so the network is still exposed to transaction ID fashability and hash time squared increases.
SegWit will slow down the networksecurityThe number of nodes performing full validation will be significantly reduced, as only those nodes that have SegWit adapted will be able to validate the Witness portion of the transaction.
SegWit cannot be abolished. If it is repealed and all changes are undone, then all SegWit output becomes money picked up by anyone on the street.
SegWit wants to fix everything at once, and as a result, it leads to a lot of code changes. It makes future work more taxing and increases the chance of software bugs that won't go away.
conclusion
While there are likely to be more elegant solutions to problems solved by SW, we still believe that this is the best way to improve the scalability of the network and unlock technological implementations like the Lightning Network at this time. A more detailed analysis will be provided in the next article.
reference
Lightning network in depth, part 1: payment channels
"Mastering Bitcoin" -- Andreas M. Antonopoulos
Bitcoin Core blog
Many segwit resources
Good article about txn malleability
The original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
