This post was initially written in Portuguese (see
here), and I first wrote because there is very little documentation about the segwit written in other languages, but I still think it's good to post here.
Sorry for any english errors.
It is an "update" that has had on the bitcoin network, opening doors for lighter, faster and cheaper transactions and also enabling the implementation of protocols such as lightning network.
More technical explanation: It is a soft-fork (BIP 141) that changes the concept of block size, putting the concept of 'weight unit' (explained later). Providing a temporary solution to the problem of scalability and the problem of malleability in transactions (also explained later).
Faster and cheaper transactions? The answer to this is
depends, creating more "cheap" transactions is only possible with the new types of address (see below), and even so, the speed for your transaction to be confirmed depends on other factors, such as miners and mempool (basically the transactions of others that were not confirmed).
New formats of address There are currently three address formats in use:
Legacy (P2PKH): These are the "old" formats, they start with the digit '1' and if you use them you continue as before, paying as before, nothing changes for you (taking the fact that you are outdated - so please use the "new" formats).
eg:
1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 P2SH (nested Segwit): They are the best for the moment, start with the digit '3' (remember the multisig wallets), with them you will have the same compatibility of the Legacy type, but with the advantage of creating witness transactions. The rate savings are around
27% (depends on the inputs and outputs). To use this format in the wallets, know that most have already adopted this one by default. (see how to create this type of address on electrum
here)
eg:
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy Bech32: Theoretically they are much better than the two mentioned above, it starts with "bc1", this type have the advantage of being better readable to the human (it only has lowercase letter), which avoids typing errors and also allow the autocomplete of the wallets and a smaller QRcode for addresses of that type. And the main thing: they do witness transactions with a much higher rate of savings, around
38% (again this depends on the inputs and outputs). The problem? almost no service recognizes this as a bitcoin address, which brings a serious compatibility problem. (if you want to use this type, the Electrum wallet already offers this).
eg:
bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdqWhy encourage the use? If you are already using a segwit address (P2SH or bech32), and you are sending money you received from another segwit address (segwit-> you-> other), then you will have a lower transaction fee than someone who is using a segwit address by spending money that came from a legacy (a "legacy input") (legacy-> you-> other) address. Again, if you are using a
legacy address nothing will change, but if everyone uses only segwit, the advantages will be greater.
If you've read so far you already have all the essential information about Segwit, read on only if you have technical curiosities about how segwit really works
What are "weight units"? With the activation of Segwit, the old unit of measurement
bytes became obsolete, and the units
vbytes and
weight unit were introduced, the relation between them is of
1 weight unit = 4 vbytes, and in the new sizes of the blocks it was
4 millions of weight units per block.
Has the block size not increased ? Would not that be a hard-fork ? No, because from this change in the blocks, the way of measuring the size of transactions also changed, and in
legacy transactions (old) the value of
byte also changed to that is, a transaction of 300
bytes is now 300
vbytes, which actually amounts to 300 * 4 = 1200 weight units , which occupies the same percentage of space in blocks as before. Now, in the transactions created using Segwit this changes completely.
The "witness" transactions Basically, when you create a transaction using segwit, the size of the transaction decreases, but if you are thinking that it is because they are fully measured in
weight units , you are also wrong, what these new addresses they can do is write some parts (specifically related to the signature) that would normally be written on a scale of
vbytes in
weight units, that is, parts of the transaction (in truth the process is more complex than it) are 4x smaller! and this is why we generally only see transactions with a rate saving of not more than 50%, also showing that it is impossible to see blocks with 4x more transactions the capacity gain of the blocks actually reaches only + 60% until + 100%).
Note: There isnt any way to rise the size of the block without a hardfork.
The problem of the malleability of transactions The problem of malleability in transactions was a problem that affected Mt.Gox in 2013, basically it was possible to change the txid of a transaction even without changing its values (origin, recipient, value) and still make it valid. What's the problem? the exchange created a transaction with a txid and the attacker adulterates this transaction with another txid and also transmits it, in the end if only the transaction of the attacker was confirmed, the exchange ended up not discounting the balance of the attacker by looking only the txid generated by they. With segwit this problem is over.
More technical part yet Leaving the transactions "lighter" was precisely what triggered the solution of malleability - to be more specific: all the segwit does is basically take the part of ScriptSig (the part that left malleable, it is possible to add useless thing inside) of the part of the transaction (the part that interferes with the hash / txid), and puts it in a region called "witness data", which is lighter (hence the space savings mentioned above), and this ends the problem of malleability and timely space.
-before and after the fork-
With the problem of malleability, since in the lightning network you have to generate new transactions based on old transactions that were not transcribed in the blockchain, and if there were the problem of "two txid same for the same transaction", this would not be possible ( it seems that there was even a solution without the need for segwit, but that made everything much more complicated).
Note: the LN will work only with "segwit adresses".
Schnorr Signatures I will not go into many details, but it is a proposal that can be implemented as well as segwit (but it depends on it), which would further reduce the size of the transactions (especially the multisig), in addition to offering more security and privacy to users.
Extra: The schnorr signature perfects and much the system called CoinJoin.
Conclusion... The use of segwit drastically reduces transaction fees, but we still need solutions that solve the problem of scalability like Lightning Network, while we should only use the resources we have, and this already helps the network as a whole.
I tried to describe the parts a little more technical without complicating much, so probably it will have many mistakes, I will be gratful if you help me to correct ths mistakes.
