Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0EADEABC for ; Mon, 20 Nov 2017 19:59:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33C098A for ; Mon, 20 Nov 2017 19:59:03 +0000 (UTC) Received: from [10.8.0.102] (119246244201.ctinets.com [119.246.244.201]) by mx.zohomail.com with SMTPS id 1511207941125564.2097344385272; Mon, 20 Nov 2017 11:59:01 -0800 (PST) From: Johnson Lau Message-Id: <24ADB268-7F46-4451-A53F-23D78CE66274@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_E9D453F8-CCA8-4B9E-8EAD-870D5636EE70" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Tue, 21 Nov 2017 03:58:57 +0800 In-Reply-To: To: Praveen Baratam References: X-Mailer: Apple Mail (2.3445.1.6) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Why SegWit Anyway? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 19:59:05 -0000 --Apple-Mail=_E9D453F8-CCA8-4B9E-8EAD-870D5636EE70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not really. BIP140 might be easier to implement, but in longterm the = UTXO overhead is significant and unnecessary. There are also other = benefits of segwit written in BIP141. Some of those are applicable even = if you are making a new coin. > On 21 Nov 2017, at 2:07 AM, Praveen Baratam = wrote: >=20 > BIP 140 looks like it solves Tx Malleability with least impact on = current practices. It is still a soft fork though. >=20 > Finally, if we were to create an alternative cyptocurrency similar to = Bitcoin, a Normalized Tx ID approach would be a better choice if I get = it right! > =E1=90=A7 >=20 > On Mon, Nov 20, 2017 at 11:15 PM, Johnson Lau > wrote: > We can=E2=80=99t =E2=80=9Cjust compute the Transaction ID the same way = the hash for signing the transaction is computed=E2=80=9D because with = different SIGHASH flags, there are 6 (actually 256) ways to hash a = transaction. >=20 > Also, changing the definition of TxID is a hardfork change, i.e. = everyone are required to upgrade or a chain split will happen. >=20 > It is possible to use =E2=80=9Cnormalised TxID=E2=80=9D (BIP140) to = fix malleability issue. As a softfork, BIP140 doesn=E2=80=99t change the = definition of TxID. Instead, the normalised txid (i.e. txid with = scriptSig removed) is used when making signature. Comparing with segwit = (BIP141), BIP140 does not have the side-effect of block size increase, = and doesn=E2=80=99t provide any incentive to control the size of UTXO = set. Also, BIP140 makes the UTXO set permanently bigger, as the database = needs to store both txid and normalised txid >=20 >> On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev = > wrote: >>=20 >> Bitcoin Noob here. Please forgive my ignorance. >>=20 >> =46rom what I understand, in SegWit, the transaction needs to be = serialized into a data structure that is different from the current one = where signatures are separated from the rest of the transaction data. >>=20 >> Why change the format at all? Why cant we just compute the = Transaction ID the same way the hash for signing the transaction is = computed? >>=20 >> --=20 >> Dr. Praveen Baratam >>=20 >> about.me = _________________________________________= ______ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 >=20 >=20 >=20 > --=20 > Dr. Praveen Baratam >=20 > about.me --Apple-Mail=_E9D453F8-CCA8-4B9E-8EAD-870D5636EE70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Not really. BIP140 might be = easier to implement, but in longterm the UTXO overhead is significant = and unnecessary. There are also other benefits of segwit written in = BIP141. Some of those are applicable even if you are making a new = coin.

On 21 Nov 2017, at 2:07 AM, Praveen Baratam = <praveen.baratam@gmail.com> wrote:

BIP 140 looks like it solves Tx Malleability with least = impact on current practices. It is still a soft fork though.

Finally, if we were to = create an alternative cyptocurrency similar to Bitcoin, a Normalized Tx = ID approach would be a better choice if I get it right!
3D""=E1=90=A7

On Mon, Nov 20, 2017 at 11:15 PM, = Johnson Lau <jl2012@xbt.hk> wrote:
We can=E2=80=99t =E2=80=9Cjust compute the = Transaction ID the same way the hash for signing the transaction is = computed=E2=80=9D because with different SIGHASH flags, there are 6 = (actually 256) ways to hash a transaction.

Also, changing the definition of TxID = is a hardfork change, i.e. everyone are required to upgrade or a chain = split will happen.

It is = possible to use =E2=80=9Cnormalised TxID=E2=80=9D (BIP140) to fix = malleability issue. As a softfork, BIP140 doesn=E2=80=99t change the = definition of TxID. Instead, the normalised txid (i.e. txid with = scriptSig removed) is used when making signature. Comparing with segwit = (BIP141), BIP140 does not have the side-effect of block size increase, = and doesn=E2=80=99t provide any incentive to control the size of UTXO = set. Also, BIP140 makes the UTXO set permanently bigger, as the database = needs to store both txid and normalised txid

On 21 Nov = 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:

Bitcoin Noob here. Please forgive my = ignorance.

=46rom what I understand, in = SegWit, the transaction needs to be serialized into a data structure = that is different from the current one where signatures are separated = from the rest of the transaction data.

Why change the format at all? Why cant we just compute the = Transaction ID the same way the hash for signing the transaction is = computed?

--
Dr. Praveen = Baratam

about.me
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




--
Dr. Praveen = Baratam

about.me

= --Apple-Mail=_E9D453F8-CCA8-4B9E-8EAD-870D5636EE70--