Clarification on how sigwit 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).

[Kelvin9ce]

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

Legacy Addresses (P2PKH)
These are the original Bitcoin addresses, easily identified by their starting digit "1" (e.g., 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa).
Legacy addresses generate larger transaction sizes because they include signatures directly in the transaction structure. This increased size consumes more block space, which often translates to higher transaction fees. The main benefit of legacy addresses is universal wallet support, given they’ve been in use since Bitcoin’s inception.

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)

[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.