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 A4D9699A for ; Wed, 17 Aug 2016 10:15:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from erelay3.ox.registrar-servers.com (erelay3.ox.registrar-servers.com [192.64.117.2]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1CD94A8 for ; Wed, 17 Aug 2016 10:15:51 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id 9B0CC2206BE5; Wed, 17 Aug 2016 10:15:50 +0000 (UTC) Received: from erelay1.ox.registrar-servers.com ([127.0.0.1]) by localhost (erelay.ox.registrar-servers.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Dspc6QKv8ofz; Wed, 17 Aug 2016 06:15:49 -0400 (EDT) Received: from MTA-10.privateemail.com (unknown [10.20.150.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by erelay1.ox.registrar-servers.com (Postfix) with ESMTPS id 40F9222067DB; Wed, 17 Aug 2016 06:15:49 -0400 (EDT) Received: from APP-06 (unknown [10.20.147.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by MTA-10.privateemail.com (Postfix) with ESMTPSA id 8DA4960038; Wed, 17 Aug 2016 10:15:48 +0000 (UTC) Date: Wed, 17 Aug 2016 06:15:48 -0400 (EDT) From: Johnson Lau Reply-To: Johnson Lau To: bitcoin-dev@lists.linuxfoundation.org, Luke Dashjr Message-ID: <703193091.96057.1471428948569@privateemail.com> In-Reply-To: <201608170440.35767.luke@dashjr.org> References: <1736097121.90204.1471369988809@privateemail.com> <976728541.94211.1471402973613@privateemail.com> <201608170440.35767.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_96056_1392606999.1471428948508" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.1-Rev18 X-Originating-Client: open-xchange-appsuite X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Wed, 17 Aug 2016 10:15:52 -0000 ------=_Part_96056_1392606999.1471428948508 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > On August 17, 2016 at 12:40 AM Luke Dashjr wrote: > > > On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote: > > To completely replicate the original behaviour, one may use: > > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} > > ELSE DROP {else script} ENDIF" > > This is much uglier than expected. IMO if that's the best workaround for the > current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if they > need to avoid malleability issues. It is ugly only if you want to faithfully replicate the behaviour. I'd argue that in no real use case you need to do this. For example, "OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must return a valid MINIMALDATA number. And your workaround does not fix malleability, since any non-0x01 values are valid FALSE However, in some case, enforcing MINIMALIF does require 1 more witness byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html I think the best strategy is to make it a relay policy first, and decide whether we want a softfork later. ------=_Part_96056_1392606999.1471428948508 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> On August 17, 2016 at 12:40 AM Luke Dashjr= <luke@dashjr.org> wrote:
>
>
> On Wednesday= , August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> &#= 62; To completely replicate the original behaviour, one may use:
> &= #62; "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {i= f script}
> > ELSE DROP {else script} ENDIF"
>
&#= 62; This is much uglier than expected. IMO if that's the best workaroun= d for the
> current behaviour, people should just use "OP_1 OP_= EQUAL OP_IF" when/if they
> need to avoid malleability issues.<= /p>

It is ugly only if you want to faithfully replicate the behaviour. I&= #39;d argue that in no real use case you need to do this. For example, "= ;OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF",= since OP_SIZE must return a valid MINIMALDATA number.

And your worka= round does not fix malleability, since any non-0x01 values are valid FALSE<= /p>

However, in some case, enforcing MINIMALIF does require 1 more witnes= s byte: https://lists.linuxfoundation.org/pipermail/b= itcoin-dev/2016-August/013036.html

I think the best strategy is t= o make it a relay policy first, and decide whether we want a softfork later= .

=20 ------=_Part_96056_1392606999.1471428948508--