Clarification on how segwit reduce transaction malleability issue

[Jibdeen]

I was doing some research about the ways to cut out transaction fees when I came across SegWit. I discovered that SegWit was introduced to fix transaction malleability and improve block space efficiency, but I’m still a bit unclear and confused on how it works under the hood.

Could someone help and explain what exactly changes in a SegWit transaction compared to a legacy one? How does this result in lower transaction fees? Why does it fix the transaction malleability issue?

And also, some examples comparing a legacy vs. SegWit transaction format would be really helpful.

[Mia Chloe]

I was doing some research about the ways to cut out transaction fees when I came across SegWit. I discovered that SegWit was introduced to fix transaction malleability and improve block space efficiency, but I’m still a bit unclear and confused on how it works under the hood.

SegWit which is Segregated Witness in full  actually changes Bitcoin transactions by separating witness data (which are actually signatures and public keys) from the main transaction data which  makes it easier to work with and also save block space and improve efficiency smaller space occupied means smaller fees paid.

However In legacy transactions, the entire transaction including witness data is hashed to create the TXID, making it far less malleable since minor witness alterations would change the TXID. SegWit actually solves this by excluding witness data from the TXID calculation.  instead it's moved to a separate "witness" field, ensuring the TXID remains fixed even if witness data is modified.

This separation actually leads to lower transaction fees because witness data in SegWit transactions is "discounted" when calculating transaction size meaning each witness byte is weighted as 0.25 bytes for fee purposes which results in a smaller effective "virtual size" known as (vbytes).

[hosemary]

If there's a legacy input in a transaction, anyone can change the transaction ID without invalidating the signature.

Assume that you make a transaction which has an unconfirmed parent including legacy input(s).
The transaction malleability allows miners to change the transaction ID of the unconfirmed parent without its signature being invalidated. Once miners include the changed parent into the blockchain, your transaction would be invalidated.

Miners are not able to do so, if all inputs of the parent are segwit.

[ABCbits]

Could someone help and explain what exactly changes in a SegWit transaction compared to a legacy one? How does this result in lower transaction fees? Why does it fix the transaction malleability issue?

Old Bitcoin Core blog answer most of your questions, see https://bitcoincore.org/en/2016/01/26/segwit-benefits/.

SegWit Addresses (P2SH and Bech32)
Segregated Witness (SegWit) was introduced to solve transaction malleability and improve block efficiency. SegWit addresses come in two main forms:

P2SH (Pay-to-Script-Hash) addresses that start with "3" (e.g., 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy)

Bech32 (Native SegWit) addresses that start with "bc1" (e.g., bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq)

Considering you posted on technical board, i should mention that.
1. SegWit address that wrapped in P2SH actually called P2SH-P2WPKH and P2SH-P2WSH. Your post imply all P2SH address as SegWit which is wrong.
2. P2WSH also exist, where it aimed to replace P2SH.
3. Bech32 initially aimed to support future upgrades, not only SegWit. But due to issue with it's error detection, it's replaced with Bech32m for Taproot and other future upgrades.

[pooya87]

To understand how SegWit works you have to have an idea about how the Bitcoin script language works. Lets start from an older soft-fork which could be interesting to know this is not the first time we do things like this.

In Bitcoin, OP_HASH160 <160-bit data> OP_EQUAL is a very simple output script. It pops the top stack element and computes its hash. Then pushes the 160-bit data on the stack and the last OP will pop the two top stack elements and pushes their equality check result back to the stack.
With a soft fork many years ago we added a new consensus rule so that whenever the interpreter saw this "output script pattern" it would follow a different verification path with new requirements. In that path it first creates a duplicate of the top stack element and treat it as a [redeem] script and evaluates that as well. Therefore the P2SH scripts were invented in a backward compatible way. Meaning the older nodes would just do what I explained first (equality check only) and upgraded nodes would additionally perform the redeem script evaluation.

Years later we took a similar approach in SegWit. An OP_NUMBER <some data> is a similarly simple output script. It just pushes 2 values to the stack and always evaluates to true (assuming the data is not zero). Through a soft fork back in in 2017 we added a new rule that told the interpreter to use a different verification path whenever it saw this output script pattern. In that verification path, the transaction needs to have a new field called "witness" which holds the stack elements needed to continue the verification. As you see the signature is not separated, it is still part of the transaction. The difference is that in order to keep things backward compatible, the old un-upgraded nodes don't need to see it.
This is why some people are still saying "SegWit separates signatures from transactions" which is not accurate.

Because this is a new field inside the transactions, it gave us the ability to change how transactions are references while keeping things backward compatible by introducing 2 hashes: txid and wtxid. Transaction ID is computed by hashing everything except the witness and Witness Transaction ID is computed by hashing everything.
Since txid is the hash that is used in transaction's inputs (in the outpoint) it fixes the malleability attacks using the signature. Now if anybody changes anything about the the signature (eg. the key owner re-signs the same tx with a different nonce) the transaction ID won't change.

Because witness is a new field, it has a good side effect as well. It effectively increases the raw block capacity to be more than the legacy 1 MB.
The reason why you end up paying less fee is not because SegWit transactions are smaller in size. In fact because there are extra bytes added to the transaction, they can be slightly bigger in raw bytes. The reason for paying less fees is because the algorithm to compute transaction fee changed from being based on size (raw bytes) to be based on weight (virtual size). When you use SegWit, you are tapping into that extra block space it provides, so you get a discount.

[gmaxwell]

I was doing some research about the ways to cut out transaction fees when I came across SegWit. I discovered that SegWit was introduced to fix transaction malleability and improve block space efficiency, but I’m still a bit unclear and confused on how it works under the hood.

SegWit which is Segregated Witness in full  actually changes Bitcoin transactions by separating witness data (which are actually signatures and public keys) from the main transaction data which  makes it easier to work with and also save block space and improve efficiency smaller space occupied means smaller fees paid.

The witness data is not separated from the transactions, it's in each transaction before the nLocktime field.   It prevents malleability attacks by separating it from the txid so that child transactions aren't invalidated by changes to the signature, the same way *within* a transaction the various signatures don't sign each other.  It doesn't change the space of anything.  It doesn't directly lower fees, but because the witness field isn't counted in the original blocksize limit the change was able to effectively eliminate the old limit and replace it with a "weight limit"-- like measuring blocks by the pound instead of by the gallon and the witness data takes up less weight.  Nothing in bitcoin sets the fees for transactions except market forces, but the increase in capacity can result in lower fees for a given amount of demand since users bid against each other for access to capacity.

[Cricktor]

OP, can you try to think for a second why it's important to have proper spelling in topic's titles? Why do you write "sigwit" when it's segwit or Segwit?

Your carelessness or ignorance hampers proper search! Assume someone tries to search for "Segwit" in topic's titles only. Result: your topic won't be found. Is this what you want?

I took the liberty to correct it at least in the Subject of my little rant here. I'm a bit puzzled how some people aren't ashamed of their topic titles, being either badly descriptive or having embarrassing mispellings that hamper searches.

[gmaxwell]

OP, can you try to think for a second why it's important to have proper spelling in topic's titles? Why do you write "sigwit" when it's segwit or Segwit?

I fixed it for them, though I doubt it matters.  Sometimes people's errors provide an informative framing.

[Jibdeen]

OP, can you try to think for a second why it's important to have proper spelling in topic's titles? Why do you write "sigwit" when it's segwit or Segwit?

I fixed it for them, though I doubt it matters.  Sometimes people's errors provide an informative framing.

Thank you @gmaxwell for the fixing, I appreciate that. It was a typographical error and I didn’t notice it.

[kanftka]

I was doing some research about the ways to cut out transaction fees when I came across SegWit. I discovered that SegWit was introduced to fix transaction malleability and improve block space efficiency, but I’m still a bit unclear and confused on how it works under the hood.

Could someone help and explain what exactly changes in a SegWit transaction compared to a legacy one? How does this result in lower transaction fees? Why does it fix the transaction malleability issue?

And also, some examples comparing a legacy vs. SegWit transaction format would be really helpful.

Yu kw, I did some digging into this sometime ago when I was trying to figure out why SegWit even matters, and TBH it’s a bit confusing at first, but it makes sense once you break it down.

First off, SegWit is not the first time Bitcoin did a kind of upgrade like this. There was something earlier called P2SH (Pay to Script Hash), where a very simple script like OP_HASH160 <somehash> OP_EQUAL would just make older nodes check if a hash matched. But then newer nodes knew to go one step further and actually run a more complex script hidden behind that hash. That was possible thanks to a soft fork, which let new rules exist without breaking the old ones.

SegWit used that same idea. The script for a SegWit output is super basic, like OP_0 <some hash> nothing fancy. But newer nodes see that and go, “okay, time to check the witness.” That is a new part of the transaction that holds the signature and pubkey.

Now here is where it gets kinda cooler.

In the old style legacy, the signature is part of what gets hashed to make the txid. So if anyone tweaks the signature, like if the same owner re signs it slightly differently, the txid also changes. That is what they mean by transaction malleability. It made some stuff like Lightning harder to build because you could not trust the txid would stay the same.

SegWit changes that. It removes the signature from the txid calculation. So even if someone tweaks the signature, the txid would not change anymore. That is how it fixes malleability.

And then about the fees, this is where I misunderstood it at first. SegWit txs are not always smaller. In fact, they can be bigger in raw bytes. But Bitcoin changed how fees are calculated, not just based on size, but weight… Witness data (the stuff in that new field) gets discounted, each byte of it only counts as 0.25 bytes when calculating how big the transaction is vbytes, basically… So yeah, SegWit transactions might take more bytes, but they’re lighter in weight, so you end up paying less.

Also, this gave Bitcoin a way to fit more into a block without bumping the block size limit directly. That’s why some people say SegWit increased the block size, it kinda did, in a roundabout way.

It took me a while to fully get it too, especially with all the jargon thrown around.

[Rgram]

The witness data is not separated from the transactions, it's in each transaction before the nLocktime field.   It prevents malleability attacks by separating it from the txid so that child transactions aren't invalidated by changes to the signature, the same way *within* a transaction the various signatures don't sign each other.  It doesn't change the space of anything.  It doesn't directly lower fees, but because the witness field isn't counted in the original blocksize limit the change was able to effectively eliminate the old limit and replace it with a "weight limit"-- like measuring blocks by the pound instead of by the gallon and the witness data takes up less weight.  Nothing in bitcoin sets the fees for transactions except market forces, but the increase in capacity can result in lower fees for a given amount of demand since users bid against each other for access to capacity.

Witness as it’s used here, is it the same thing as signatures? Or just a code name for the later.

From the much I’ve had to consume, the main difference between the legacy and segwit transitions is largely due to this separation of signatures.
Where in the case of the segwit, each signature doesn’t sit next to an input (unspent output) but rather, the raw input as Bitcoin data is processed as a whole and validated by the signature at the end while, in the case of legacy, the signature validation is done per input processing which consumes more and is reflected in the fees.

[pooya87]

Witness as it’s used here, is it the same thing as signatures? Or just a code name for the later.

Witness is the stack elements that are needed to complete the script evaluation. Depending on the script type being spent, it can contain different things. For example when spending a P2WPKH output the witness contains the public key and the signature as two items. To spend a P2WSH it contains the redeem script.