<p>SegWit was introduced to solve Bitcoin's slow transaction speed and congestion issues caused by a 1 MB block size limit (separating transaction signatures from transaction data). This boosts the block's capability without a hard fork. And achieved lower transaction fee.
This link might be helpful.
<a href="https://blockgeeks.com/guides/what-is-segwit/" rel="nofollow noreferrer">https://blockgeeks.com/guides/what-is-segwit/</a></p>

CC BY-SA 4.0
2023-08-23T03:42:06.087Z
2023-08-23T03:42:06.087Z
Mani T
<p>I am currently learning about <em>SegWit</em> and trying to understand what it is used for. It is clear to me that it was primarily introduced to overcome <strong>txid malleability</strong>, but...</p>
<p>Looking at <a href="https://bitcoin.stackexchange.com/questions/117153/is-a-transaction-with-a-non-segwit-input-still-considered-malleable-if-so-how/117168">this question</a> and <a href="https://bitcoin.stackexchange.com/a/117168/140802">the answer</a> looks like Bitcoin, by updating the way that Bitcoin script works, disabled the <strong>txid malleability</strong> even without <em>SegWit</em>. So you can no longer add additional content to the script, keep it valid and have a different ID. So, <strong>txid malleability</strong> is not anymore possible, not just through using <em>SegWit</em>, but also by using legacy transactions (P2PKH) and the unlocking script field. In the first answer to the referenced question, <em>Antoine Poinsot</em> also talks about third-party malleability, but as he said, <em>SegWit</em> is not the solution for that, so it can't be the purpose of why <em>SegWit</em> is used today.</p>
<p><strong>So if overcoming txid malleability, as the main reason why <em>SegWit</em> was introduced, is no longer the main advantage of <em>SegWit</em> (since it can also be overcome without <em>SegWit</em>), what is?</strong></p>
<p>One advantage/purpose, I would say, could be that there is an indication of the version of the script being used, so that the script language can be extended very easily.</p>
<p><strong>What are the other advantages/purposes of <em>SegWit</em> today (not just today, but in general)?</strong></p>

CC BY-SA 4.0
2023-08-19T22:02:06.017Z
You seem confused by terminology; lots of sources use different names for these phenomena. However, if a transaction today does not have exclusively segwit inputs, then txids of presigned transactions are completely unreliable, making any system relying on those (including Lightning) practically infeasible. That is not due to third party malleability, but just because any participant in the transaction can produce a different signature, which would (before segwit) change the txid. Some people also call that malleability, some don't.
Pieter Wuille
CC BY-SA 4.0
2023-08-19T22:23:10.593Z
@PieterWuille If I got it right, you wanna say that even if, after all changes how the script works, third party can't anymore add any additional content to the script, keep it valid and make another ID, it is still possible that one of the participant in transaction, for example, create new valid signature (different random value in ECDSA), change the ID and damage the systems such as Lightning and other participant. By using SegWit we protect from the first case, that is now not even possible in traditional P2PKH, but also from the second one (which is possible in P2PKH). Did I get it right?
dassd
CC BY-SA 4.0
2023-08-19T22:27:53.013Z
It's complicated, these things don't exactly overlap. While script changes like BIP66 and BIP62 (only a policy rule) make it impossible for third parties (e.g. miners, relay nodes on the network) to alter the txid of a transaction without invalidating it (only for specific simple transactions even), that is not what matters to e.g. Lightning. The concern there is about transactions created by *multiple* parties, and another party (but a co-signer) changing the txid by changing their signature, without invalidating your own. Segwit *completely* fixes that problem, while BIP62/66 are unrelated.
Pieter Wuille
CC BY-SA 4.0
2023-08-19T22:32:55.020Z
Further, it's not like it's in general not possible to modify segwit transactions anymore without invalidating them. It's just possible for parties to make sure that when that happens, the txid won't change.
Pieter Wuille
CC BY-SA 4.0
2023-08-19T22:51:41.603Z
@PieterWuille Yes, yes, that's what I'm pointing out. So even with all the changes like BIP66 and BIP62, a third party won't be able (let's assume it won't be, maybe there is still some way for it) to change the txid without invalidating it (so you wouldn't need SegWit for this purpose), for a transaction created by multiple parties it is still possible that one (incorrect - say Byzantine) participant changes the transaction ID by changing its signature. Here, BIP66 and BIP62 changes and traditional transactions cannot help, and only using SegWit and "constant" ID would help. Am I right?
dassd
CC BY-SA 4.0
2023-08-19T22:59:02.937Z
That sounds right.
Pieter Wuille
CC BY-SA 4.0
2023-08-19T23:07:15.737Z
@PieterWuille In your previous comment you wrote "just a policy rule". Is it a validity rule or a standardness rule (a rule for forwarding a transaction to other peers)? If the changes are made only to standardness rule, that means even with all the changes (BIP66, BIP62) transaction malleability in traditional transactions can still be done by miners?
dassd
CC BY-SA 4.0
2023-08-19T23:13:17.310Z
BIP66 is a consensus/validity rule, which activated as a softfork in july 2015. BIP62 was originally intended as a consensus rule too, but never adopted as such (in part because fixing all malleability avenues is a game of whack-a-mole, and cannot possibly guarantee txid predictability of presigned transactions anyway; segwit was a much more thorough solution of those). Some parts of BIP62 have however been adopted as a policy/standardness rule in Bitcoin Core.
Pieter Wuille
CC BY-SA 4.0
2023-08-19T23:18:55.923Z
@PieterWuille Oh, right, thanks Pieter. So, overcoming transaction malleability is still one of the main advantages of SegWit. As one of the additional advantage I mentioned version number and easy script updating. Are there any other important advantages?
dassd
CC BY-SA 4.0
2023-08-19T23:26:19.143Z
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Pieter Wuille
CC BY-SA 4.0
2023-08-19T23:27:28.467Z
@PieterWuille Thanks Pieter, all the best!
dassd
<segregated-witness><transaction-malleability>
What are the main advantages/purposes of SegWit today?
dassd
# What are the main advantages/purposes of SegWit today?

(Asked by: username_0 on 2023-08-19)

I am currently learning about *SegWit* and trying to understand what it is used for. It is clear to me that it was primarily introduced to overcome **txid malleability**, but...

Looking at [this question](https://bitcoin.stackexchange.com/questions/117153/is-a-transaction-with-a-non-segwit-input-still-considered-malleable-if-so-how/117168) and [the answer](https://bitcoin.stackexchange.com/a/117168/140802) looks like Bitcoin, by updating the way that Bitcoin script works, disabled the **txid malleability** even without *SegWit*. So you can no longer add additional content to the script, keep it valid and have a different ID. So, **txid malleability** is not anymore possible, not just through using *SegWit*, but also by using legacy transactions (P2PKH) and the unlocking script field. In the first answer to the referenced question, *Antoine Poinsot* also talks about third-party malleability, but as he said, *SegWit* is not the solution for that, so it can't be the purpose of why *SegWit* is used today.

**So if overcoming txid malleability, as the main reason why *SegWit* was introduced, is no longer the main advantage of *SegWit* (since it can also be overcome without *SegWit*), what is?**

One advantage/purpose, I would say, could be that there is an indication of the version of the script being used, so that the script language can be extended very easily.

**What are the other advantages/purposes of *SegWit* today (not just today, but in general)?**

**Tags:** segregated-witness, transaction-malleability

> **Comments:**
> **username_1**: You seem confused by terminology; lots of sources use different names for these phenomena. However, if a transaction today does not have exclusively segwit inputs, then txids of presigned transactions are completely unreliable, making any system relying on those (including Lightning) practically infeasible. That is not due to third party malleability, but just because any participant in the transaction can produce a different signature, which would (before segwit) change the txid. Some people also call that malleability, some don't.  
> **username_0**: @username_1 If I got it right, you wanna say that even if, after all changes how the script works, third party can't anymore add any additional content to the script, keep it valid and make another ID, it is still possible that one of the participant in transaction, for example, create new valid signature (different random value in ECDSA), change the ID and damage the systems such as Lightning and other participant. By using SegWit we protect from the first case, that is now not even possible in traditional P2PKH, but also from the second one (which is possible in P2PKH). Did I get it right?  
> **username_1**: It's complicated, these things don't exactly overlap. While script changes like BIP66 and BIP62 (only a policy rule) make it impossible for third parties (e.g. miners, relay nodes on the network) to alter the txid of a transaction without invalidating it (only for specific simple transactions even), that is not what matters to e.g. Lightning. The concern there is about transactions created by *multiple* parties, and another party (but a co-signer) changing the txid by changing their signature, without invalidating your own. Segwit *completely* fixes that problem, while BIP62/66 are unrelated.  
> **username_1**: Further, it's not like it's in general not possible to modify segwit transactions anymore without invalidating them. It's just possible for parties to make sure that when that happens, the txid won't change.  
> **username_0**: @username_1 Yes, yes, that's what I'm pointing out. So even with all the changes like BIP66 and BIP62, a third party won't be able (let's assume it won't be, maybe there is still some way for it) to change the txid without invalidating it (so you wouldn't need SegWit for this purpose), for a transaction created by multiple parties it is still possible that one (incorrect - say Byzantine) participant changes the transaction ID by changing its signature. Here, BIP66 and BIP62 changes and traditional transactions cannot help, and only using SegWit and "constant" ID would help. Am I right?  
> **username_1**: That sounds right.  
> **username_0**: @username_1 In your previous comment you wrote "just a policy rule". Is it a validity rule or a standardness rule (a rule for forwarding a transaction to other peers)? If the changes are made only to standardness rule, that means even with all the changes (BIP66, BIP62) transaction malleability in traditional transactions can still be done by miners?  
> **username_1**: BIP66 is a consensus/validity rule, which activated as a softfork in july 2015. BIP62 was originally intended as a consensus rule too, but never adopted as such (in part because fixing all malleability avenues is a game of whack-a-mole, and cannot possibly guarantee txid predictability of presigned transactions anyway; segwit was a much more thorough solution of those). Some parts of BIP62 have however been adopted as a policy/standardness rule in Bitcoin Core.  
> **username_0**: @username_1 Oh, right, thanks username_1. So, overcoming transaction malleability is still one of the main advantages of SegWit. As one of the additional advantage I mentioned version number and easy script updating. Are there any other important advantages?  
> **username_1**: https://bitcoincore.org/en/2016/01/26/segwit-benefits/  
> **username_0**: @username_1 Thanks username_1, all the best!  

---

## 1 answers

### Answer by username_2 on 2023-08-23. Score: -2

SegWit was introduced to solve Bitcoin's slow transaction speed and congestion issues caused by a 1 MB block size limit (separating transaction signatures from transaction data). This boosts the block's capability without a hard fork. And achieved lower transaction fee.
This link might be helpful.
<https://blockgeeks.com/guides/what-is-segwit/>


---

