Segregated Witness for Dummies
Bitcoin scalability is one of its main problems, which is being actively addressed. One of the representatives of these solutions is, for example, the Lightning network technology, but its implementation is not yet possible due to some vulnerabilities. Another solution - Segregated Witness is also aimed at increasing scalability, but it also solves a number of problems, including the very vulnerability that hinders the implementation of lightning. In this article we will look at the main benefits of Segregated Witness, and also describe the mechanism of its work.
Segregated witness, or as many call it SegWit, is a soft fork, described in the BIP series (141, 142, 143, 144 and 145), the main goal of which is to optimize the structure of transactions and blocks by making signatures (what call ' scriptSig ', ' witness ' or ' unlocking script ') from a transaction to a separate structure. This not only reduces the size of transactions, makes the blocks more capacious, but also solves the problem of their “variability” ( transaction malleability , we discussed this vulnerability above), which is very important for technologies like payment channels or lightning relying on the structure of the transaction bitcoin
How it works
Before we begin
To begin with, let's briefly recall what the payment system in Bitcoin is. There is nothing in it like a list of balances as it can be implemented in any bank. Instead, the balance of each address is represented by a set of transactions sent to this address, where the transaction is a structure in which the inputs (inputs) and outputs (outputs) are the main ones. Inputs are transactions that we refer to to spend (more precisely, they are not transactions in full, but their specific outputs, because in one transaction we can transfer funds to several addresses), and outputs are addresses to which we We want to transfer funds. This is the structure of a Bitcoin transaction:
The PubKey script field (hereinafter scriptPubKey ) in the outputs is what is called the locking script . It is necessary so that only the owner of the address to which the funds are listed can take advantage of this exit. The Signature Script field (hereinafter scriptSig ) is also called unlocking script - it unlocks the locking script, providing proof of ownership of the address.
More information about transactions, as well as the work of the locking and unlocking script can be read here .
Backward compability
In fact, Segregated Witness changes not only the structure of the transaction, but also its outputs. This, however, does not mean that in the same transaction both traditional UTXO (unspent transaction outputs) and Segwit ones cannot be spent - just the first ones will expect "proof" inside the input (the scriptSig field), and the second - outside.
Since Segregated Witness is still a software fork, its updates can be ignored, which means that older systems should somehow handle the Segwit outputs. The fact is that for old nodes or wallets, these exits look like accessible to everyone, that is, they can be spent with an empty signature, which is still valid. Accepted update nodes and wallets will certainly look for all the signatures outside the entrances in a special field 'witness'.
Examples
Pay-to-Witness-Public-Key-Hash
Now let's take a look at sample transactions and how they will change with Segregated Witness. We will start with a standard Pay-to-Public-Key-Hash (P2PKH) transaction.
We are interested in exits, namely their "scriptPubKey" fields. Consider a typical locking script:
OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG With Segregated Witness, it will look like this:
0 <PubKeyHash> As you can see, the Segvit exit is much simpler than the traditional one - it consists of two values that will be placed on the stack of the script execution. As we mentioned earlier, for older versions of the Bitcoin client, this output will be visible as accessible to anyone, since it does not require a signature. But for the updated client, the first number is interpreted as a version number, and the second as an analogue of the locking script (witness program). In fact, the compressed public key hash should be used here, we will tell about it a little later.
Now let's look at the transaction in which this output will be spent. In the traditional case, it would look like this:
[...] "Vin" : [ { "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011", "vout": 0, "scriptSig": "<our scriptSig>" } ] [...] However, to spend the Segvit exit, a transaction must have an empty sriptSig field and contain all the signatures in a separate place:
[...] "Vin" : [ { "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011", "vout": 0, "scriptSig": "" } ] [...] "witness": "<Witness data>" [...] Warning
Despite the fact that traditional customers can process Segvit transactions (remember that their exits look like everything is available to old customers), they cannot waste their exits because they simply don’t know how to do it: the old type wallet will try to spend Segvit’s exit with a blank signature, but this transaction is not really valid (nodes that have Segregated Witness, will not miss such a transaction). This means that the sender needs to know whether the purse of the recipient supports the segwit or not in order to create outputs of the desired type.
Starting from BIP 143, outputs should be created using a compressed public key hash. If you create an exit using a regular address or an uncompressed public key, this output will be unused.
Pay-to-Witness-Script-Hash
The next very important type of transaction is P2SH - it allows you to send transactions to the hash of the script instead of the hash of the public key (the usual Bitcoin address). To spend the output of the P2SH transaction you need to provide a script (it is called the redeem script), the hash of which matches the hash of the script to which the funds are sent, as well as signatures / passwords / something else depending on the script. Using this approach, you can send bitcoins to an address protected by a way that we don’t know anything about, and also save a lot of space - in the case of, for example, a multisignature wallet, the locking script would be really great if we stored everything. ” locks "completely, not just their hash.
So, let's take as an example a multi-signature wallet that requires 2 signatures from 5. In the traditional form, the locking script for exiting a P2SH transaction looks like this:
HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL To spend it, you need to provide a redeem script that defines the condition of a multi-signature 2 out of 5, as well as 2 signatures, and all of this must be in the input of the transaction:
[...] "Vin" : [ "txid": "abcdef12345...", "vout": 0, "scriptSig": "<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>", ] Now let's take a look at what it would look like if both the sender and receiver used Segregated Witness.
Locking script output:
0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73 Again, as in the case of the P2PKH transaction, the resulting script is much simpler. Here, the 1st value is the version number, and the second is the 32-byte SHA256 hash of the redeem script (witness program). This hash function was chosen in order to somehow distinguish the witness program P2WPKH from the one for P2WSH according to the hash length (32 bytes SHA256 and 20 bytes RIPEMD160 (SHA256 (script))).
A transaction using this output:
[...] "Vin" : [ "txid": "abcdef12345...", "vout": 0, "scriptSig": "", ] [...] "witness": "<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>" [...] Embedding Segregated Witness inside P2SH
So, we have seen that using Segregated Witness has its advantages, however, for the examples above, both the sender and the recipient must be updated, which is not always possible. Consider, for example, the following situation:
Alice wants to send bitcoins to Bob, but she doesn’t have a segwit wallet, while Bob has one. Of course, they can just use a standard transaction, but Bob wants to use segwit to reduce the commission.
In this case, Bob can create a P2SH address containing a segwit script. For Alice, he will be seen as the most usual P2SH address and she will be able to transfer funds to him without any problems, and Bob will be able to spend this output using a segwit transaction and receive a discount on the commission (we will tell about the new setting of the commission for segwit transactions below) .
Thus, both types of segvit transactions - P2WSH and P2WPKH can be implemented inside P2SH.
P2SH (P2WPKH)
To use the P2WPKH transaction inside the P2SH, Bob needs to create a witness program from his public key. Then the result needs to be hashed and converted to the P2SH address:
Create a witness program:
0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 As usual - the 1st number is the version and the 2nd is the 20 byte hash of the public key. The resulting script is then hashed SHA256 and then RIPEMD160, producing the next 20 byte hash.
HASH160 from witness program P2WPKH:
3e0547268b3b19288b3adef9719ec8659f4b2b0b And convert to the address:
37Lx99uaGn5avKBxiW26HjedQE3LrDCZru Locking script output sent to this address will look like a script for a regular P2SH address:
HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b EQUAL Now consider how Bob can spend this exit:
[...] "Vin" : [ { "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011", "vout": 0, "scriptSig": "0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7" } ] [...] "witness": "<Witness data>" [...] First, the redeem script provided by us (in our case, this is the witness program) will be hashed and, if it is equal to the hash specified in the locking script, it will be executed and the signatures in the "witness" field will be checked.
P2SH (P2WSH)
Similarly, any P2WSH script can be implemented inside P2SH. Take the multisig script 2 of 5, discussed earlier. All steps will be almost identical to the case of P2SH (P2WPKH):
To begin with, again, create a witness program:
0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73 The first number is the version, the second is a 32 byte SHA256 hash of our multi-signature script. Then the steps are repeated - we take the HASH160 from the witness program and convert it to a regular P2SH address. To use the output sent to this address, in the scriptSig you need to record the witness program, and all signatures and the full multisiga script in the witness field.
Segregated witness benefits
Now, when we have dealt with the technical part, we consider the main advantages of segregated witness.
Transaction malleability
One of the most important problems that segwit solves is the “volatility” of transactions, or more precisely, their IDs, which are hashes. We will understand a little more.
In the traditional case, the signatures that are inside the transaction at the entrances can be changed by a third party without their invalidation. This allows you to change the transaction ID, which is its hash, without changing any "fundamental" fields like inputs / outputs / amounts of funds. Thus, the transaction is still valid, but now has a different ID, which creates the possibility for all sorts of attacks , for example denial-of-service.
Segwit solves this problem, because all the signatures are outside the transaction, which means they are not hashed and their change will not affect the transaction ID in any way. A separate identifier wtxid is also introduced - it hashes not only the transaction but also the entire witness part, so if the transaction is transmitted without witness data, then txid is equal to wtxid.
Solving this problem allows you to create chains of unconfirmed transactions without any risk — a very important feature for protocols such as the Lightning Network.
Network and Storage Scaling
Witness data is often the largest part of a transaction. In scripts like multisig, they can take up to 75% of the space used by a transaction. Thanks to segwit, the transfer of signatures becomes optional - the node only requests them if it is going to validate the transaction. SPV ( simple payment verification ) clients or nodes that do not support segvit, in this case, may not download extra data, saving disk space.
Block size increase and lower transaction fees
Segwit transactions are cheaper than the traditional ones due to the discount on witness data storage. To be more precise, the very notion of "size" for segwit transactions was changed. Instead of the usual size, they introduced the concept of "virtual size" (virtual size) - all data stored in the "witness" is taken into account with a coefficient of 0.25, which also allows you to place more transactions in the block. Consider an example.
Suppose we have a traditional transaction size of 200 bytes. In a block of size 1 MB fit 5000 of these. Now take its segwit equivalent, where approximately 120 bytes is the witness data. Then its vsize = 80 + 0.25 * 120 = 110 and now 9090 such transactions will fit into the block. Also at commission, for example, at 40 satoshi / byte for the 1st transaction we will receive a commission of 8000 satoshi, and for the 2nd 4400 satoshi, which is almost two times less.
Script Versioning
As you may have noticed, each locking script has a byte responsible for the version of the script. The use of versions allows you to make additions and changes (changes in syntax, new operators, etc.) in the form of soft forks.
Signature Verification Optimization
Segregated Witness also optimizes the work of algorithms with signatures (CHECKSIG, CHECKMULTISIG, etc.). Before segwit, the number of hash calculations increased quadratically with the number of signatures, while in the update the complexity of the algorithm was reduced to O (n).
So what is the problem?
So if everything is so good, what's the problem? The update has many opponents in the network, because despite all the obvious advantages, it also has its weaknesses. Consider some of the arguments against.
- Since segwit is a software fork, far from all clients will be updated, which means that two types of UTXO will be on the network at the same time, and such important changes as eliminating the vulnerability of transaction id and hashing in linear time will not be applied to non-Segwit outputs, which means the network will still be vulnerable to attacks based on transaction id variability, as well as the problem of quadratic hashing time.
- Segwit can reduce network security. The number of nodes performing full validation will be greatly reduced, since only those who have accepted segwit will be able to check witness part of the transaction.
- Segwit cannot be undone. If you cancel it and roll back all changes back, all segwit-outputs will be available to everyone.
- Segwit tries to solve all problems at once and, as a result, a huge amount of code is changed. This complicates further work and increases the likelihood of bugs that will be more difficult to eliminate.
Conclusion
Despite the fact that, perhaps, for the problems solved by SW, more elegant solutions can be provided, we believe that at the moment this is a great way to increase the scalability of the network, as well as to make possible the introduction of technologies such as the Lightning Network, which we are reviewing in detail also spend in the following articles.
References
"Mastering bitcoin" - Andreas M. Antonopoulos
')
Source: https://habr.com/ru/post/349812/
All Articles