From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9820ECAC for ; Mon, 20 Nov 2017 17:45:28 +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 BF27155C for ; Mon, 20 Nov 2017 17:45:26 +0000 (UTC) Received: from [10.8.0.102] (119246244201.ctinets.com [119.246.244.201]) by mx.zohomail.com with SMTPS id 1511199922653339.47954356304626; Mon, 20 Nov 2017 09:45:22 -0800 (PST) From: Johnson Lau Content-Type: multipart/alternative; boundary="Apple-Mail=_2F38892E-E85A-4E1A-8C5E-36A21E85027D" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Tue, 21 Nov 2017 01:45:18 +0800 References: To: Praveen Baratam , bitcoin-dev In-Reply-To: Message-Id: 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 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 17:45:28 -0000 --Apple-Mail=_2F38892E-E85A-4E1A-8C5E-36A21E85027D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = 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 --Apple-Mail=_2F38892E-E85A-4E1A-8C5E-36A21E85027D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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<= br class=3D"">

= --Apple-Mail=_2F38892E-E85A-4E1A-8C5E-36A21E85027D--