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 8F459BAC for ; Tue, 21 Nov 2017 13:10:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com [74.125.83.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C952D1E1 for ; Tue, 21 Nov 2017 13:10:29 +0000 (UTC) Received: by mail-pg0-f43.google.com with SMTP id 4so10134639pge.1 for ; Tue, 21 Nov 2017 05:10:29 -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; bh=a/UDVMTzmGyQGBkGJGHe+wb6iLCxCnZ5b9WhiobBEao=; b=ehQVSNPcGuEasZSROvLhTIWh5Sm34hmfFN2cGikRMO2yqRk3DV3V8Fxon9/z1uH5M+ ShCFzzH4Skz55LmXzd23sHBWYedV80ce4muygql2fMxNNFpF8CMrzWh7Pu2j+KURz6Ar iymjZCG+N/c0soksEr0n1EfskwBB7vf35YbGZL9FXAx8sdOIut1fYmPm/3KPD4pPpiUU KeFGgelx9h7dhISoZlgB2MbX1dHtXXWS6Mfk5jq7pJLMTk5ZlRpYAbYa19rYC6FpQGci 9PRWTPxA4lqk6/WwH+5NXs0oEeEgF9du6nKk9x8BlDVF/waSfij+N9iXKf1nx2y5NsyF WHFw== 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; bh=a/UDVMTzmGyQGBkGJGHe+wb6iLCxCnZ5b9WhiobBEao=; b=L89V7O6wWTw9LWlUi4k0hveSmGRPru+UITiqqxlrUcFyTct6YZPys94MP6gzsRbEVN eL4jUx8p62V60DyPTxcEqZTqmAbRgXy8Q8fB/uqX4zl4xUwFYLyKJI0U6KGZQThTrCBm Ltc2+PVzdXB0AhpkKGfFTJV8nN79gM2N07uhTQ7JTpxHBRuDLTJSDm81PdKlBPapk4d8 NxoIusXBbWPuIa3aT5uBVh8tcg9iSld3j3bbosvxz1VwP/X3wNRDkv4HdTamK/5TBRjF mHQKjnDgT+sDugOI1+obxCNX5ScjDjh7+qhUe+ZXcQHNVbx5PR8PMRnXw7bdwuTUtuFt BXuA== X-Gm-Message-State: AJaThX4elrs6ateFTj3Q3/AuvrSy6d0lezR5JdF29t4lTgOwcuIxOLJV gcYmyid2V0K5rJFI5oRykU0jO/UU+Tg25RGLskA= X-Google-Smtp-Source: AGs4zMZZFs1oR9IKhNkQJtMq0dlRNV9GWe46foKc0EtZ/FcffWXETIlX8rTgoXATNegN+nWCj6+Sn2EKIMWcIM+goss= X-Received: by 10.84.137.106 with SMTP id 97mr6755342plm.429.1511269829381; Tue, 21 Nov 2017 05:10:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.135.86 with HTTP; Tue, 21 Nov 2017 05:10:28 -0800 (PST) Received: by 10.100.135.86 with HTTP; Tue, 21 Nov 2017 05:10:28 -0800 (PST) In-Reply-To: References: From: Steve Shadders Date: Tue, 21 Nov 2017 23:10:28 +1000 Message-ID: To: DKBryant@gmail.com, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c13ee245711e7055e7dedde" 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 14:01:31 +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: Tue, 21 Nov 2017 13:10:30 -0000 --94eb2c13ee245711e7055e7dedde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is incentive because of artificially distorted block weight rules. It is favourable for a miner to choose a segwit tx over a non segwit tx as they can fit more of them into a block and earn more fees. On Nov 21, 2017 11:06 PM, "Dan Bryant via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 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 > > > > _______________________________________________ > 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 > > --94eb2c13ee245711e7055e7dedde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is incentive because of artificially distorted bloc= k weight rules. It is favourable for a miner to choose a segwit tx over a n= on segwit tx as they can fit more of them into a block and earn more fees.<= /div>

On Nov 21, 2= 017 11:06 PM, "Dan Bryant via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
Is there any incentive for miners to pick segwit transaction= s over non-segwit transaction.=C2=A0 Do they require less, equal, or more c= ompute to process?

On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev" &l= t;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 tr= ansaction is computed=E2=80=9D because with different SIGHASH flags, there = are 6 (actually 256) ways to hash a transaction.

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

It = is possible to use =E2=80=9Cnormalised TxID=E2=80=9D (BIP140) to fix mallea= bility issue. As a softfork, BIP140 doesn=E2=80=99t change the definition o= f 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 a= ny incentive to control the size of UTXO set. Also, BIP140 makes the UTXO s= et permanently bigger, as the database needs to store both txid and normali= sed txid

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

Bitcoin Noob here. Please forgive my ignorance.
=
From what I understand, in SegWit, the transaction needs to be se= rialized 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 Transac= tion ID the same way the hash for signing the transaction is computed?

--
Dr. Praveen Baratam
_______________________________________________


______________________________________= _________
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

--94eb2c13ee245711e7055e7dedde--