Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 947E7C7C for ; Mon, 20 Nov 2017 18:08:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C16F9517 for ; Mon, 20 Nov 2017 18:08:02 +0000 (UTC) Received: by mail-wm0-f49.google.com with SMTP id u83so12145792wmb.5 for ; Mon, 20 Nov 2017 10:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=31T86SEjWa+G9+wZ54bOCrHrzYy2w/KxO+Sv9wG7P14=; b=fUOhIA6qNLcfyr8ruf7kkUvbLtgupwGMo8d4cUclw4MbXuZxPujAr/xogGrSw24hvU M26sqVfOW0oQQd6LYvzwI+X23xTM79tbkdeinX/ST6mhdC3BpqjSK+CDWjNS6rOy+/so qbSnVxy0/xtDAyFzBdIO+DxuDO+Mmd1/uyNmo57vDwLIzuASOypERjOyqS92YaDVRFF8 XnNjuzJjqJbrnSfAs9nBtahOdHtJwhpTs5m4wjPO0IUi8iZmWOXjr6hJLcanBb9TKxnY cycKJy0tUBHtOU9PIUKJHPHWnZVir/sUnBOaHcY7onC434sQJEeu8GIEtvlE2ko5nCVa b1iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=31T86SEjWa+G9+wZ54bOCrHrzYy2w/KxO+Sv9wG7P14=; b=PZd8iaIy00AzCufcgC2kEBQQ1zkeN3yM1mz1HQDhGgc6OVIfOOAp4uFbwbFmci/3V5 KDuFGq1gWHJNVmeD2A8MnNyxJYSL6WAqpePqbZd5YjpQ8IDr0x2VA1b9gMjgeQjMxcBp rT36oKwoFuTm7uqNzdNd2NTiwy8r2kZ3wdIan/vJwWQ4IaUhIPWXpq+Vi9oEpuRbhtZQ zRrsL1+tuttonq0x98ax0zUyWdXlLaR09M6DbJZ2QfUN8AAmZrAR/pXApSFXrWupRGL7 4I4x+4Hjd6BvEI6Xpj4fSuaqPqr7AbL5KulZ0gR5mGryTJ7ya3NP9txoyHdOwldv6/f/ RREw== X-Gm-Message-State: AJaThX4jETeC4iYJZIhC5XhlJsUJs79fcohVWfluogZBOEF0cFfIwTga FB9e4K1/sXpoUh1jKM9I8CCWcuVYBKBIBCHd52Y= X-Google-Smtp-Source: AGs4zMbsWhDKS4129kdHxbSpFovoU2z6TWWU3lGj/F5TVXCahPVqMYCaddDkuHrbjm4jb4o7OlcydNeS3bRDZPv6a/k= X-Received: by 10.28.212.69 with SMTP id l66mr10297391wmg.33.1511201281191; Mon, 20 Nov 2017 10:08:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.225.6 with HTTP; Mon, 20 Nov 2017 10:07:40 -0800 (PST) In-Reply-To: References: From: Praveen Baratam Date: Mon, 20 Nov 2017 23:37:40 +0530 Message-ID: To: Johnson Lau Content-Type: multipart/alternative; boundary="001a11469a608cb48a055e6df75f" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Tue, 21 Nov 2017 13:06:37 +0000 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 18:08:03 -0000 --001a11469a608cb48a055e6df75f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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! =E1=90=A7 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 th= e hash for > signing the transaction is computed=E2=80=9D because with different SIGHA= SH 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 m= alleability > issue. As a softfork, BIP140 doesn=E2=80=99t change the definition of TxI= D. > Instead, the normalised txid (i.e. txid with scriptSig removed) is used > when making signature. Comparing with segwit (BIP141), BIP140 does not ha= ve > the side-effect of block size increase, and doesn=E2=80=99t provide any i= ncentive > to control the size of UTXO set. Also, BIP140 makes the UTXO set > permanently bigger, as the database needs to store both txid and normalis= ed > 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. > > From 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 > > > --=20 Dr. Praveen Baratam about.me --001a11469a608cb48a055e6df75f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BIP 140 looks like it solves Tx Malleability with least im= pact on current practices. It is still a soft fork though.

Finally, if we were to create an alternative cyptocurrency similar to Bi= tcoin, a Normalized Tx ID approach would be a better choice if I get it rig= ht!
<= font color=3D"#ffffff" size=3D"1">=E1=90=A7

On Mon, Nov 20, 2017 at 11:15 PM, Jo= hnson Lau <jl2012@xbt.hk> wrote:
We= can=E2=80=99t =E2=80=9Cjust compute the Transaction ID the same way the ha= sh 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 cha= nge, 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 ch= ange the definition of TxID. Instead, the normalised txid (i.e. txid with s= criptSig removed) is used when making signature. Comparing with segwit (BIP= 141), BIP140 does not have the side-effect of block size increase, and does= n=E2=80=99t provide any incentive to control the size of UTXO set. Also, BI= P140 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 b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Bitcoin Noob here. Please forg= ive my ignorance.

From what I understand, in SegWit, th= e transaction needs to be serialized into a data structure that is differen= t 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 t= ransaction is computed?

--
Dr. Praveen Baratam
<= br>
_______________________________________________
bi= tcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/= bitcoin-dev




--
Dr. Praveen Baratam
--001a11469a608cb48a055e6df75f--