Why SegWit Anyway?



Summary:

The discussion revolves around the issue of transaction malleability and the proposed solutions- BIP140 and SegWit (BIP141). While BIP140 is a soft fork that uses normalized TxID, which does not change the definition of TxID, SegWit changes the format of transactions and separates signatures from the rest of the transaction data. The supporters of BIP140 argue that it is easier to implement than SegWit and avoids the unnecessary overhead of UTXO, which SegWit brings. However, changing the definition of TxID is a hardfork change and requires everyone to upgrade, or it will lead to a chain split. Furthermore, the BIP140 solution makes the UTXO set permanently bigger, as the database needs to store both txid and normalized txid. Johnson Lau also points out that there are different SIGHASH flags, leading to six different ways to hash a transaction, making it impossible to compute the Transaction ID the same way the hash for signing the transaction is computed. In conclusion, while both solutions have their benefits and drawbacks, it seems that BIP140 is an easier implementation but has some significant inefficiencies in the long term, whereas SegWit provides more comprehensive solutions but involves a more complex implementation process.


Updated on: 2023-05-20T04:22:21.724471+00:00