The scalability problem of Bitcoin is one of the main problems it faces, and it is also the direction of many people’s efforts. For example, there is an idea of the “Lightning Network”; however, the conditions for the realization of the Lightning Network in the Bitcoin network do not seem to be available, because of some shortcomings of Bitcoin itself. Another solution, “Segregated Witness” is also dedicated to improving scalability, but it also solves many problems, including some defects that need to be fixed for the Lightning Network implementation. In this article, we will explain the advantages of Segregated Witness and how it works.
Segregated Witness (SegWit) is a soft fork described by multiple BIPs (141, 142, 143, 144, and 145). Its main purpose is to optimize the structure of Bitcoin transactions and blocks, and to sign transactions (also called ” “Script signature (scriptSig)”, “witness” or “unlocking script”) moved from the transaction to a separate structure. It not only allows to reduce the data size of Bitcoin transactions (thus allowing more transactions to be filled in a block), but also solves the problem of ” transaction malleability ” (that is, we mentioned at the beginning that hindering the realization of the Lightning Network The defect) is extremely critical for technologies such as payment channels and the Lightning Network based on the Bitcoin transaction structure.
How does Segregated Witness work
Let’s first briefly review the Bitcoin payment system. It is not like a bank, it is a list of accounts and balances. On the contrary, the balance of each Bitcoin address is represented by a series of transactions sent to this address; the main part of the data structure of the transaction is the input and output. The input is the previous transaction we want to spend (to be precise, the input will not be a complete transaction, but the output of a certain transaction, because we may transfer funds to multiple addresses in a transaction), The output of the transaction is the destination address to which our funds are sent. The following figure shows the structure of Bitcoin transactions:
The PubKey Script field in the output (hereinafter referred to as “scriptPubKey”) is what we call “lock script”. It is used to ensure that only the owner of the receiving address can use the expenditure. The Signature Script field (hereinafter referred to as “scriptSig”) is also known as the “unlocking script” because it is the key used to open the locked script and is used to prove the ownership of the address.
(Editor’s note: Here is a gif animation showing how the Bitcoin stack is executed, but it cannot be displayed in the WeChat public account tweet. It is strongly recommended to watch it on the website.)
For more details about Bitcoin transactions and the functions of locking and unlocking scripts, please see here.
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 UTXO (unspent transaction output) and SegWit UTXO cannot be spent in the same transaction: in this case, the traditional UTXO will load the proof of ownership in the input (script signature field) , While the UTXO of the Segregated Witness type will load the proof in the structure other than the transaction input.
In any case, the positioning of Segregated Witness is a soft fork. This upgrade should be negligible and does not need to be mandatory. Moreover, this also means that unupgraded nodes should be able to handle the output of Segregated Witness type. In fact, the old nodes and wallets will think that anyone can spend these UTXOs, that is, these UTXOs can be spent with empty signatures, so even if the signature is not seen in the transaction, the transaction is still valid. The upgraded node and wallet will look for signatures in a special “witness” field outside of the transaction input.
Let’s use an example to illustrate how Segregated Witness can change the data structure of a transaction. Start with the standard Pay-to-Public-Key-Hash (P2PKH) transaction type.
The part we are interested in is the output, especially its “scriptPubKey” field (locked script field). Let us first consider a standard locking script:
The locking script after Segregated Witness is as follows:
As you can see, the output of Segregated Witness is much simpler than the traditional type of output: only two values will be pushed into the script execution stack. As we said above, the old version of the Bitcoin client would think that this output is money that fell on the ground-this output can be spent without providing a signature. However, the new client will interpret the first number as a version number, while the second corresponds to a lock script (witness program). In reality, only the hash value of the compressed public key can be used here. We will talk about this later.
Let’s take a look at the situation when this output is spent. The data structure of the output of a traditional transaction when it is spent is as follows:
However, when spending a segregated witness output, the scriptSig of the transaction will be empty, and all signatures will be placed in a special place:
Although traditional clients can handle Segregated Witness transactions (again, they will treat these outputs as money that adults can spend), but they cannot spend the money themselves: old wallets may try to spend them with empty signatures The output of a segregated witness is used, but this transaction is invalid in reality (the updated node will not allow such a transaction to be on the chain). This means that the sender must know that the recipient’s wallet does not support Segregated Witness in order to create a suitable type of output for it.
As defined by BIP 143, the output of Segregated Witness should be created with the hash value of the compressed public key. If you use a traditional type of address or the hash value of an uncompressed public key, this output will become unusable (your coins will be locked).
Another key transaction type is P2SH. It allows transactions to be sent to the hash value of the script (not the hash value of the public key, which is the Bitcoin address). To spend the output of a 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 a signature/password/other things based on this script. This usage can protect the unlocking script so that the sender cannot know the content of an address, and can also save space: for example, the locking script of a multi-signature wallet may be very long, so we must save the entire lock; With P2SH, only one hash value can be saved.
Suppose there is a multi-signature wallet that needs to provide the signature of 2 of the 5 private keys to be used. If you use a traditional transaction, the locking script output by the P2SH transaction will be as follows:
When you want to spend it, the spender (also the recipient of the last transaction) needs to provide a redemption script, which defines the spending conditions (multi-signature, 2-5), and two signatures. All of this must be placed in the input of the transaction:let’s look at the sender and receiver after using Segregated Witness. The output lock script is as follows:
Just like the P2PKH transaction, the output script becomes simpler. The first value represents the version number, and the second is the SHA256 hash value (32 bits) corresponding to the redemption script (witness program). In a sense, this function is used to distinguish between the witness program of P2WPKH and the witness program of P2WSH (32-byte SHA256 hash value vs. RIPEMD160(SHA256(script))) by length.
The transaction using this output looks like this:
Embedding Segregated Witness in P2SH
We have seen that there are benefits to using Segregated Witness. However, the above example only applies to situations where both the sender and the receiver have upgraded software. But the reality is not always the case. Consider such a situation:
Alice hopes to transfer some btc to Bob. Bob has wallet software that supports Segregated Witness but she does not. Obviously they can only use standard forms of transactions, but Bob hopes to use SegWit to reduce handling fees.
At this time, Bob can create a P2SH address containing the SegWit script, and Alice will treat this address as a normal P2SH address, so he can transfer money directly to this address without any problems. But Bob can use the SegWit transaction to use this output and get a commission discount (we will explain the new pricing method of the commission for SegWit transactions below).
This is how the two types of SegWit transactions, P2WSH and P2WPKH, are implemented in P2SH.
To implement a P2WPKH transaction in a P2SH transaction, Bob needs to use his public key to create a witness program. 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 value. This script performs the SHA256 hash operation first, and then the RIPEMD160 operation, and a 20-byte hash value can be obtained.
The HASH160 result of this P2WPKH witness program:
Converted into an address:
The output lock script sent to this address seems to be the same as a script with a normal P2SH address:
Then when Bob spends the output, the structure of the transaction will look like this:
At the beginning, the redemption script we created (that is, the witness program) will undergo a hash calculation. If the result matches the hash value in the lock script, the script will be executed and the program will verify the value placed in the witness field sign.
P2WSH scripts can also be implemented with P2SH. Let us consider the 2-5 multi-signature wallet example mentioned above. All the steps are no different from P2SH (P2WPKH):
First, create a witness program:
Benefits of Segregated Witness
After sorting out the technical parts, we can understand the main advantages of Segregated Witness.
Transaction fusion vulnerability
A key problem solved by SegWit is the “fusion” of Bitcoin transactions, that is, the problem caused by the fact that the ID of a Bitcoin transaction is a hash value. Let’s talk about it in detail.
In previous 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 transaction ID (that is, the hash value of the transaction) without changing the “key” fields of the transaction (such as the number of inputs, outputs, and transfers) at all. In this way, the transaction is still valid and the meaning is still the same, but with another ID, this can be used to perform another attack, such as a DoS attack (Denial of Service attack).
SegWit solves this problem, because all signatures are placed outside the transaction, so the change of the signature will not cause the hash value of the transaction to change, and it will not affect the ID of the transaction. Segregated Witness also introduces a special identifier called “wtxid”: it is the hash value of the transaction and the entire witness part, so if a transaction is propagated without any witness data, the transaction ID (txid) is equal to wtxid .
This solution allows us to create a series of successive unconfirmed transactions without worrying about any risks, which is very important for protocols like the Lightning Network. (Translator’s Note: The meaning here may be that if the issue of transaction fusion is not resolved, the participants of the payment channel will not be able to quickly retrieve whether the opponent has put an outdated channel transaction on the chain, because the transaction of the same content may be completely Different IDs appear).
Network and storage expansion
Witness data is often the largest part of transaction data. In transactions that use multi-signature scripts, witness may account for up to 75% of the transaction data volume. Thanks to SegWit, the transmission of the signature has become an option: only the node needs to request this data when it wants to verify the transaction. And SPV (Simple Payment Verification) clients and nodes that do not support SegWit do not need to download additional data, which can save hard disk space.
The available block space expands and transaction fees are reduced
The SegWit type of transaction is cheaper than the previous transaction type because it reduces the witness data that needs to be stored. To be precise, the concept of “Size” (data size) is slightly different in SegWit type transactions. It introduces the concept of “virtual size”: all the data placed in the witness part will be multiplied by 0.25 to calculate the data size, so that more transactions can be packed in a block. Let’s look at an example.
Suppose we have a traditional type of transaction with a data size of 200 bytes. Then 5000 such transactions can be put in a 1MB block. An equivalent SigWit transaction has 120 bytes in the witness area, so its virtual size is 80 + 0.25 * 120 = 110 bytes, so the block can fit 9090 such transactions. If the transaction fee on the chain is 40 satoshis per byte, the transaction fee will be reduced from 8000 satoshis to 4400 satoshis, which is almost a half discount. (Translator’s Note: “Satoshi” is the unit of Bitcoin, which is one billionth of btc.)
You may have noticed that each locked script has 1 byte to indicate the version of the script. Using different version numbers can add or change features (syntax changes, new operators, etc.) in the form of soft forks.
Efficiency optimization of signature verification
Segregated Witness also optimizes the efficiency of signature algorithms (such as CHECKSIG, CHECKMULTISIG, etc.). Before SegWit, the number of hash calculations was proportional to the square of the number of signatures, but with Segregated Witness, the computational complexity of the algorithm was reduced to O(n) (proportional to the number of signatures).
What’s the problem?
If there is nothing wrong with all profits, how can anyone think that there is a problem? Many people in the Bitcoin community oppose this upgrade because, even though it has so many advantages, it also has some disadvantages. Let’s take a look at some of the opinions put forward by the opponents.
- Because SegWit is a soft fork, many clients may not upgrade, so two types of UTXO will exist in the network at the same time; major changes such as elimination of transaction ID fusion and linear increase in the number of hash calculations are for non-SegWit output Invalid, so the network will still be exposed to the risk of transaction ID melting and the square of hash time rising.
- SegWit will reduce the security of the network, and the number of nodes performing full verification will be greatly reduced, because only those nodes that are adapted to SegWit have the ability to verify the witness part of the transaction.
- SegWit cannot be abolished. If it is repealed and all changes are undone, then all SegWit output will become money picked up by anyone on the street.
- SegWit hopes to solve all the problems at once, and because of this, it has caused a lot of code changes. It will make future workloads more loaded and increase the chances of software bugs that cannot go away.
Although the problem solved by SW is likely to have a more elegant solution, we still believe that, at present, this is the best way to improve the scalability of the network and enable the implementation of technologies such as the Lightning Network. For a more detailed analysis, we will put it in the next article.
- Lightning network in depth, part 1: payment channels
- “Mastering bitcoin” — Andreas M. Antonopoulos
- Bitcoin Core blog
- Many follow resources
- Good article about txn malleability
Author: Magomed Aliev
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/detailed-explanation-of-segregated-witness/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.