<oembed><type>rich</type><version>1.0</version><author_name>npub14sz60zalvsz094ekxmgq2xpcsr67a9aljeqcny479lc8mpsp95jqfwv9e3</author_name><author_url>https://nostr.ae/npub14sz60zalvsz094ekxmgq2xpcsr67a9aljeqcny479lc8mpsp95jqfwv9e3</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2017-11-20&#xA;📝 Original message:BIP 140 looks like it solves Tx Malleability with least impact on current&#xA;practices. It is still a soft fork though.&#xA;&#xA;Finally, if we were to create an alternative cyptocurrency similar to&#xA;Bitcoin, a Normalized Tx ID approach would be a better choice if I get it&#xA;right!&#xA;ᐧ&#xA;&#xA;On Mon, Nov 20, 2017 at 11:15 PM, Johnson Lau &lt;jl2012 at xbt.hk&gt; wrote:&#xA;&#xA;&gt; We can’t “just compute the Transaction ID the same way the hash for&#xA;&gt; signing the transaction is computed” because with different SIGHASH flags,&#xA;&gt; there are 6 (actually 256) ways to hash a transaction.&#xA;&gt;&#xA;&gt; Also, changing the definition of TxID is a hardfork change, i.e. everyone&#xA;&gt; are required to upgrade or a chain split will happen.&#xA;&gt;&#xA;&gt; It is possible to use “normalised TxID” (BIP140) to fix malleability&#xA;&gt; issue. As a softfork, BIP140 doesn’t change the definition of TxID.&#xA;&gt; Instead, the normalised txid (i.e. txid with scriptSig removed) is used&#xA;&gt; when making signature. Comparing with segwit (BIP141), BIP140 does not have&#xA;&gt; the side-effect of block size increase, and doesn’t provide any incentive&#xA;&gt; to control the size of UTXO set. Also, BIP140 makes the UTXO set&#xA;&gt; permanently bigger, as the database needs to store both txid and normalised&#xA;&gt; txid&#xA;&gt;&#xA;&gt; On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev &lt;&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt;&#xA;&gt; Bitcoin Noob here. Please forgive my ignorance.&#xA;&gt;&#xA;&gt; From what I understand, in SegWit, the transaction needs to be serialized&#xA;&gt; into a data structure that is different from the current one where&#xA;&gt; signatures are separated from the rest of the transaction data.&#xA;&gt;&#xA;&gt; Why change the format at all? Why cant we just compute the Transaction ID&#xA;&gt; the same way the hash for signing the transaction is computed?&#xA;&gt;&#xA;&gt; --&#xA;&gt; Dr. Praveen Baratam&#xA;&gt;&#xA;&gt; about.me &lt;http://about.me/praveen.baratam&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;&#xA;&gt;&#xA;&gt;&#xA;&#xA;&#xA;-- &#xA;Dr. Praveen Baratam&#xA;&#xA;about.me &lt;http://about.me/praveen.baratam&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171120/35d7fb17/attachment.html&gt;</html></oembed>