SegWit (Segregated Witness) is the term given to a modification in the way Bitcoin’s transaction data is stored on the blockchain.
The term “segregate” refers to the process of separating, whereas “witnesses” refers to the transaction signatures. Thus, separated witness refers to the separation of transaction signatures.
SegWit is a technique that increases a blockchain’s block size limit by deleting signature data from bitcoin transactions. When portions of a transaction are deleted, room or capacity for further transactions in the chain is created.
SegWit enhances Bitcoin and resolves many problems.
The primary benefit of SegWit was that it quadrupled the capacity of the Bitcoin network. And, despite many assertions, SegWit did not raise the block size. It is very obvious that SegWit resulted in a block size increase.
We can observe the weight of the Bitcoin Genesis block (Size 0.285 KB) in the following table:
Here, for example, we can see one of the last 1,527 KB (1.52 MB) Bitcoin blocks mined on 9/30/2021:
Along with boosting Bitcoin’s transaction processing capacity, SegWit addressed a vulnerability in the Bitcoin protocol that enabled nodes to alter the TXIDs of network transactions. Previously, this issue was referred to as the “transaction malleability error.”
If all of the necessary criteria are satisfied, a user may convert the transaction ID to expenditure before the network can validate it. This makes it simpler to pretend that this transaction never occurred, which is advantageous for someone wishing to claim that they transferred money to another party when, in reality, they did not.
It’s comparable to getting a product from Amazon and saying that you never got it, backed up with a fictitious Fedex tracking number. That is how the deal became bendable.
Segregated Witness, often shortened as SegWit, was a 2017 update to Bitcoin Core. SegWit enhanced many elements of Bitcoin and paved the way for future enhancements, such as Taproot.
To begin, and most importantly, SegWit eliminated transaction malleability. Additionally, it increased Bitcoin’s block size limit, allowing for the inclusion of more transactions in each block. Finally, SegWit included two new script types—methods for transmitting and receiving bitcoin—as well as a new encoding technique known as Bech32.
Transaction malleability refers to a transaction’s ability to have numerous legitimate transaction identifiers. Malleability refers to the ability of a component of a transaction to change after it has been signed without invalidating the signature. Because a txid is a hash of the transaction, every modification to the transaction results in a modification to the txid. Changes to the txid that invalidate the signatures, on the other hand, are not a problem; only changes to the txid that do not invalidate the signature raise malleability issues.
Segwit enhanced the number of transactions that could be included in a block and eliminated the transaction malleability issue by eliminating what is referred to as “token data” or “signature data” from the input field of a block.
Transactions get smaller, allowing for the inclusion of more in a block. Additionally, once token data is deleted, there is no way to modify a transaction’s TXID.
Malleability is a challenge for developers and users who want to make a reference to a prior transaction in a new spending transaction before the previous transaction is verified on the blockchain. This issue occurs because in order to spend bitcoin generated by a prior transaction, the spending transaction must provide the preceding transaction’s txid. If this txid is capable of changing, the reference will fail, rendering the spending transaction illegitimate.
More precisely, transaction malleability was a barrier to the Lightning Network’s adoption, since it relied on the exchange of unconfirmed Bitcoin transactions.
Two methods exist for malleating a transaction. To begin, extra data may be added to a ScriptSig, the portion of a transaction that contains the signature and other data necessary to release the bitcoin. Second, the signature included inside the ScriptSig may be modified. Both of these possibilities are conceivable due to the fact that a signature cannot sign itself and therefore cannot become immutable. Because the ScriptSig and the signatures included inside it are part of the txid preimage, if they are modified, the txid will be modified as well.
SegWit removes this option by purging the ScriptSig of all data. This is done by relocating the ScriptSig data—typically signatures and public keys—to the Witness, a new component of SegWit transactions that is not hashed in order to compute the transaction’s txid. Thus, after signing, the ScriptSig for SegWit inputs becomes immutable, but the data needed to unlock bitcoin, which is not immutable, is included in the Witness. This implies that the ScriptSig cannot be altered without invalidating the whole transaction.
SegWit activation allowed the Lightning Network to be launched as a second layer on top of the Bitcoin network. Until SegWit was enabled, the Lightning Network was impractical because it depended largely on unconfirmed bitcoin transactions and was therefore vulnerable to attack as long as transaction malleability existed.