To understand why SegWit came about, we need to start with how bitcoin transactions are constructed. Bitcoin transaction data basically contains data that locks and unlocks bitcoins. An example transaction data is
010000000110ddd830599b17cc690535f7df28a84466eaca3c22f0d55b79023b6570f4fbc5010000008b483045022100e6186d6f344ce4df46b2e15d87093d34edbf5b50462b6b45f9bd499a6a62fbc4022055f56a1c4a24ea6be61564593c4196b47478a25cf596c1baf59f5a9a229b637c014104a41e997b6656bc4f5dd1f9b9df3b4884cbec254d3b71d928587695b0df0a80417432f4ca6276bc620b1f04308e82e70015a40f597d8260912f801e4b62ab089effffffff0200e9c829010000001976a9146f34d3811aded1df870359f311c2a11a015e945388ac00e40b54020000001976a91470d6734de69c1ac8913892f2df9be0e738d26c2d88ac00000000
This transaction spends from and pays to a Pay-to-PubKey-Hash (P2PKH) addresses which was the standard script type before SegWit. When deserialized, it looks like this
{
"version": "01000000",
"inputcount": "01",
"inputs": [
{
"txid": "10ddd830599b17cc690535f7df28a84466eaca3c22f0d55b79023b6570f4fbc5",
"vout": "01000000",
"scriptsigsize": "8b",
"scriptsig": "483045022100e6186d6f344ce4df46b2e15d87093d34edbf5b50462b6b45f9bd499a6a62fbc4022055f56a1c4a24ea6be61564593c4196b47478a25cf596c1baf59f5a9a229b637c014104a41e997b6656bc4f5dd1f9b9df3b4884cbec254d3b71d928587695b0df0a80417432f4ca6276bc620b1f04308e82e70015a40f597d8260912f801e4b62ab089e",
"sequence": "ffffffff"
}
],
"outputcount": "02",
"outputs": [
{
"amount": "00e9c82901000000",
"scriptpubkeysize": "19",
"scriptpubkey": "76a9146f34d3811aded1df870359f311c2a11a015e945388ac"
},
{
"amount": "00e40b5402000000",
"scriptpubkeysize": "19",
"scriptpubkey": "76a91470d6734de69c1ac8913892f2df9be0e738d26c2d88ac"
}
],
"locktime": "00000000"
}
Enter fullscreen mode Exit fullscreen mode
The scriptSig field which contains the signature is large and makes up a significant portion of the total transaction size, which accounts for about 60% of the blockchain size.
The transaction data above is used to compute the transaction id (txid) which serve as a reference for the relation between two transaction points. As you can see in the deserialized data above, each input has a txid field which points to the transaction that created the output that is about to be spent by being used as an input in this transaction. You can also search for a transaction on a blockexplorer by using its txid.
Ideally, txids are meant to be immutable, because it is a unique identifier of a transaction. This was exploited in the past by malicious peers because the signature could be tampered with by adding spaces or changing a thing or two that would still make the signature valid but the txid would be different. For example, if the signature contained a 3, a malicious peer could change that to 7 + 3 – 7 which still equals 3 and therefore make the signature valid because ideally nothing changed but the transaction id would be completely different. The implication of this was that if a transaction with a txid A was made and before it was confirmed, someone else modified the transaction to have a new txid B. The modified txid gets added to the blockchain and then trying to check for the transaction with txid A would always not return anything because that particular transaction’s txid has been changed. This is widely known as the transaction malleability problem. This also made it difficult for the Lightning Network protocol to function as proposed because how it operates is by spending and receiving unconfirmed transactions, so changing their txids could prove costly by invalidating a lot of transactions and making it impossible for outputs to be used as inputs in new transactions.
The proposal of SegWit brought about a handful of improvements and fixes to the bitcoin ecosystem. It proposed moving the signature which is what could be tampered with to generate a new txid for the same transaction into a new field called the witness field. The witness field would be excluded when computating the txid so changes to the signature and other fields that the witness field accommodates would not affect the txid and this made layer two protocols like the Lightning Network possible to operate as expected.
Another benefit of SegWit implementation was effectively increasing the block size by introducing a new way to measure block data known as block weight. Block weight is defined as (Base size * 3) + Total size where base size is the block size in bytes with the original transaction serialized without any witness related data and total size is the block size in bytes with transactions serialized including the base data and witness data. The limit of block weight was set as 4 million units. This introduction would see SegWit transactions weigh lighter than non-SegWit transactions, and since miners charge for fees using the weight of transactions, SegWit transactions would effectively be charged lower fees.
Script versions is a technical trick employed by SegWit to make it easier to deploy future upgrades to the Bitcoin protocol. It exists so that a script’s spending rules can change entirely just by incrementing a number in the output script without needing a new address format or breaking how older nodes relay and store the transaction. Here is the same kind of transaction like the one above but restructured for SegWit:
{
"version": "01000000",
"marker": "00",
"flag": "01",
"inputcount": "01",
"inputs": [
{
"txid": "3c735f81c1a0115af2e735554fb271ace18c32a3faf443f9db40cb9a11ca6311",
"vout": "00000000",
"scriptsigsize": "00",
"scriptsig": "",
"sequence": "ffffffff"
}
],
"outputcount": "02",
"outputs": [
{
"amount": "b113030000000000",
"scriptpubkeysize": "16",
"scriptpubkey": "0014689a681c462536ad7d735b497511e527e9f59245"
},
{
"amount": "cf12000000000000",
"scriptpubkeysize": "16",
"scriptpubkey": "00148859f1e9ef3ba438e2ec317f8524ed41f8f06c6a"
}
],
"witness": [
{
"stackitems": "02",
"0": {
"size": "47",
"item": "30440220424772d4ad659960d4f1b541fd853f7da62e8cf505c2f16585dc7c8cf643fe9a02207fbc63b9cf317fc41402b2e7f6fdc1b01f1b43c5456cf9b547fe9645a16dcb1501"
},
"1": {
"size": "21",
"item": "032533cb19cf37842556dd2168b1c7b6f3a70cff25a6ff4d4b76f2889d2c88a3f2"
}
}
],
"locktime": "00000000"
}
Enter fullscreen mode Exit fullscreen mode
More SegWit benefits can be found here
We can see the additional witness field to the transaction and the scriptsig in the input is empty and the scriptsigsize is 00. Segwit was activated as a soft fork in 2017, it being a soft fork meant it was a backward compatible upgrade which means that nodes that do not have SegWit activated yet would still process Segwit transactions the way they would normally and would not reject them and cause a split in the network
References: