Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EF1AE8B1 for ; Tue, 16 Aug 2016 22:23:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3BFE2FF for ; Tue, 16 Aug 2016 22:23:22 +0000 (UTC) Received: by mail-ua0-f178.google.com with SMTP id n59so145289740uan.2 for ; Tue, 16 Aug 2016 15:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=UGB0aN+DN07dob6s8QJ1NbOoo+i3C/MVp3GqSLv9A4I=; b=m5V76RDmdTAoI5SYmZ+FxG2y6KHhaAZCOvN4YjiTgk36rCJa5/WiTcwOT4MhrbPlK0 nfvWBWkq/mUwGm1JP94Nx50338o2i0vrQ5C5Ub3rdGJm3jWqTyRrUlpBpWbIG4PqRoux /QrIMdqqGadPBaosBybFChGyiEhrh06biwyMpd3jvSqz2cwx9KzOiw3ffggPKL5J8oAG d1VKl3loJYgg+ihSrhnI1t0P0+B99oeqMjqS4b2KIKXPA4mwuxxT1v8kHk3Wy3rQdTxB 46lOK4CNcHWC+OcoonogpmlMjSwI+Ncf8SDainVcqkgydT1y71unkbrKhKw1pJ8Ahe44 BdAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=UGB0aN+DN07dob6s8QJ1NbOoo+i3C/MVp3GqSLv9A4I=; b=KHgAwSNAK0VCh3XDC+dEl2OX6JhFCYEpxY9xLFlUw/bql7JTngV7HcTxcZ8K2ZCuEY Hvx4NwQbro5OGt5WJDGJlQz+Jq+oXZ5kXQWKbpWr+bvzuIFrIC9K5rYzgn8stclev6fr pR+TO7qQsV9MQ5618yf7PmRqwwpOWEIu768Jo9UyIEHMqGqGX1FC/Pdy4nuWPQ6dSRh8 PpQUVLz0YDnWnmKlZIU6wFUM20DhuxKbVNVXjt2TnNz1IVfaBSz9OhMLkDNOhIAlPd61 POHED0BNG3KDLGPoWeW80FDw4T7URcYu8lOhtuxYmulIDlMHSS2WOFsc5qXcbsNcYq81 0/fw== X-Gm-Message-State: AEkoouuLH22HhSbSxS7wyd0lYKhesf0zE/9RJuS0EqT8wCmlQkUOWYUmKFGhNaI/Jeni9uNZkh0S8vy9gsFTuEKP X-Received: by 10.159.40.163 with SMTP id d32mr18173551uad.115.1471386201124; Tue, 16 Aug 2016 15:23:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.45 with HTTP; Tue, 16 Aug 2016 15:23:00 -0700 (PDT) In-Reply-To: <20160816194332.GA5888@fedora-21-dvm> References: <1736097121.90204.1471369988809@privateemail.com> <201608161937.20748.luke@dashjr.org> <20160816194332.GA5888@fedora-21-dvm> From: "Russell O'Connor" Date: Tue, 16 Aug 2016 18:23:00 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c1227d0d8890a053a37cb55 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH 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, 16 Aug 2016 22:23:23 -0000 --94eb2c1227d0d8890a053a37cb55 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 16, 2016 at 07:37:19PM +0000, Luke Dashjr via bitcoin-dev > wrote: > > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote: > > > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in > > > P2WSH: > > > https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki > > > https://github.com/bitcoin/bitcoin/pull/8526 > > > > I am not sure this makes sense. SegWit transactions are already > non-malleable > > due to skipping the witness data in calculating the transaction id. What > is > > the benefit to this? > > SegWit txids aren't malleable, but segwit transactions as a whole still > are. > For instance, I could mess with a segwit transaction by replacing part of > the > witness that is used as an argument to an OP_IF with a much larger push, > potentially making the transaction larger, thus making it not get mined > due to > the higher fee. There are also potential legal issues if someone replaces a > push with data where posession in your jurisdiction is illegal. > If one's goal is to mess with an transaction to prevent it from being mined, it is more effective to just not relay the transaction rather than to mess with the witness. Given two transactions with the same txid and different witness data, miners and good nodes ought to mine/relay the version with the lower cost (smaller?) witness data. Worries about "illegal data" appearing in the blockchain is not an issue worth writing a soft-fork over. There may be good reasons for this BIP, but I don't think the reasons give above are good. --94eb2c1227d0d8890a053a37cb55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Aug 16, 2016 at 07= :37:19PM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wro= te:
> > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleabilit= y in
> > P2WSH:
> > https://github.com/jl= 2012/bips/blob/minimalif/bip-minimalif.mediawiki
> > https://github.com/bitcoin/bitcoin/pull/8= 526
>
> I am not sure this makes sense. SegWit transactions are already non-ma= lleable
> due to skipping the witness data in calculating the transaction id. Wh= at is
> the benefit to this?

SegWit txids aren't malleable, but segwit transactions as a whol= e still are.
For instance, I could mess with a segwit transaction by replacing part of t= he
witness that is used as an argument to an OP_IF with a much larger push, potentially making the transaction larger, thus making it not get mined due= to
the higher fee. There are also potential legal issues if someone replaces a=
push with data where posession in your jurisdiction is illegal.

If one's goal is to mess with an transaction t= o prevent it from being mined, it is more effective to just not relay the t= ransaction rather than to mess with the witness.=C2=A0 Given two transactio= ns with the same txid and different witness data, miners and good nodes oug= ht to mine/relay the version with the lower cost (smaller?) witness data.
Worries about "illegal data" appearing in the bl= ockchain is not an issue worth writing a soft-fork over.

= There may be good reasons for this BIP, but I don't think the reasons g= ive above are good.

--94eb2c1227d0d8890a053a37cb55--