2

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 and the answer 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)?

Filip
  • 423
  • 8
  • 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. – Pieter Wuille Aug 19 '23 at 22:02
  • @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? – Filip Aug 19 '23 at 22:23
  • 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. – Pieter Wuille Aug 19 '23 at 22:27
  • 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. – Pieter Wuille Aug 19 '23 at 22:32
  • @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? – Filip Aug 19 '23 at 22:51
  • 1
    That sounds right. – Pieter Wuille Aug 19 '23 at 22:59
  • @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? – Filip Aug 19 '23 at 23:07
  • 2
    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 Aug 19 '23 at 23:13
  • @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? – Filip Aug 19 '23 at 23:18
  • 2
    https://bitcoincore.org/en/2016/01/26/segwit-benefits/ – Pieter Wuille Aug 19 '23 at 23:26
  • @PieterWuille Thanks Pieter, all the best! – Filip Aug 19 '23 at 23:27

1 Answers1

0

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/

Mani T
  • 75
  • 6