Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4A9DFC92 for ; Mon, 20 Nov 2017 18:04:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1C131AE for ; Mon, 20 Nov 2017 18:04:11 +0000 (UTC) Received: by mail-io0-f170.google.com with SMTP id v21so16665583ioi.4 for ; Mon, 20 Nov 2017 10:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VO4ZWD19uzb6eKrfL6UhUox+KKnYrHDQsAxQdolZykA=; b=ffdxcfIdDWpmRYhZmaW9PX14sX4QHtptOR55ph/4iGv+qltCBKgcD4OMnBMbzHdZFl kSxJkiK1/yF7Y5xnkm5wSCBvGeLpOpElhZQPnrvrkm+VqSOAhRh1sH1MW6ivH7nI8oLB cmDv0Nf8tPjk5LJXbak+sRgU8BBCXSKA+SHQpnG9zxDmYyJq9lDGqxgVK8vDbByoC5Fb PWEoa439zDKeb6DWziiHehKRSfrlnP+p/eohDlsEL043YYoT5VycBmkGxPKwiSkvXLZ2 h9+cgXWB0Kyk74R6t/GUWcYFIBDmauhqX6wcYcAZOVSX+olftgo9BcDQTvpwXHqwo51q WMrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=VO4ZWD19uzb6eKrfL6UhUox+KKnYrHDQsAxQdolZykA=; b=kHJUlFM0ruS9WRmZs8sM2GswtJyAqrA522O2zKhwzOnQjyCmN2hhTbyrTKwLtIEHHX C+W7/mx5282yJE6EjTfjdtYhW6m/AudJSUKi4CVhtsMdwjV/Zvki0ltkKT8zrg8Jj4Oq nu1WzxnCK5SPafNzEl+WPdUNlDikM0Sj91KW0Ilmm7yzUohYwWfauoC1bTfDHB9qs9ZY KaL14/7Nc2FNuY1nPrhpW1anR9JC+N4RmsZ5BsElOHXCazc6F7f7YFYKjqPFyHIpa6EG oCA7Ywu19dnqAFwPrKN47eBDs8O93LrjqbA80Ke5rF1V7OQJtvjiig/YuE164lP0fhZI MClQ== X-Gm-Message-State: AJaThX4sKnaQVsawvAJHDYWcrr83dvCMgr0N/AVG0X5V1LAS6B+XU1cd PU9tDfmG1WmEuiVtHFzTuVneqbfixD8BhB7Tjds= X-Google-Smtp-Source: AGs4zMbSAQhLKyCgFld3faVL2XbkOTjaHwq3U6aAg1X4KDN/fVeI1Nmt1z8PBFKoCGHuBP0UJT3Khe/zZe1BA0JPqlc= X-Received: by 10.107.16.206 with SMTP id 75mr15043063ioq.83.1511201050685; Mon, 20 Nov 2017 10:04:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.4.213 with HTTP; Mon, 20 Nov 2017 10:04:09 -0800 (PST) Received: by 10.107.4.213 with HTTP; Mon, 20 Nov 2017 10:04:09 -0800 (PST) Reply-To: DKBryant@gmail.com In-Reply-To: References: From: Dan Bryant Date: Mon, 20 Nov 2017 12:04:09 -0600 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org, Johnson Lau Content-Type: multipart/alternative; boundary="001a113eda96cf7f63055e6de94b" 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:15 +0000 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:04:12 -0000 --001a113eda96cf7f63055e6de94b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is there any incentive for miners to pick segwit transactions over non-segwit transaction. Do they require less, equal, or more compute to process? On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> 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 mal= leability issue. As a softfork, BIP140 doesn=E2=80=99t change the definition of TxID. Instea= d, 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 incenti= ve 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. 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? --=20 Dr. Praveen Baratam about.me _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --001a113eda96cf7f63055e6de94b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there any incentive for miners to pick segwit transact= ions over non-segwit transaction.=C2=A0 Do they require less, equal, or mor= e compute to process?

On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev"= <bitcoin-dev@l= ists.linuxfoundation.org> 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 transac= tion.

Also, changing the definition of TxID is a h= ardfork 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 wit= h segwit (BIP141), BIP140 does not have the side-effect of block size incre= ase, 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 ne= eds to store both txid and normalised txid
=

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


--001a113eda96cf7f63055e6de94b--