Date: Wed, 17 Aug 2016 06:15:48 -0400 (EDT)
From: Johnson Lau <jl2012@xbt.hk>
Reply-To: Johnson Lau <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org, Luke Dashjr <luke@dashjr.org>
Message-ID: <703193091.96057.1471428948569@privateemail.com>
In-Reply-To: <201608170440.35767.luke@dashjr.org>
References: <1736097121.90204.1471369988809@privateemail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
	<976728541.94211.1471402973613@privateemail.com>
	<201608170440.35767.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_96056_1392606999.1471428948508"
Importance: Medium
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
Precedence: list

------=_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 <luke@dashjr.org> 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

<!DOCTYPE html>
<html><head>
    <meta charset=3D"UTF-8">
</head><body><p><br></p><p>&#62; On August 17, 2016 at 12:40 AM Luke Dashjr=
 &#60;luke@dashjr.org&#62; wrote:<br>&#62; <br>&#62; <br>&#62; On Wednesday=
, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:<br>&#62; &#=
62; To completely replicate the original behaviour, one may use:<br>&#62; &=
#62; &#34;DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {i=
f script}<br>&#62; &#62; ELSE DROP {else script} ENDIF&#34;<br>&#62; <br>&#=
62; This is much uglier than expected. IMO if that&#39;s the best workaroun=
d for the <br>&#62; current behaviour, people should just use &#34;OP_1 OP_=
EQUAL OP_IF&#34; when/if they <br>&#62; need to avoid malleability issues.<=
/p><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, &#34=
;OP_SIZE OP_IF&#34; could just become &#34;OP_SIZE OP_0NOTEQUAL OP_IF&#34;,=
 since OP_SIZE must return a valid MINIMALDATA number.</p><p>And your worka=
round does not fix malleability, since any non-0x01 values are valid FALSE<=
/p><p>However, in some case, enforcing MINIMALIF does require 1 more witnes=
s byte:&#160;<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2016-August/013036.html">https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2016-August/013036.html</a></p><p>I think the best strategy is t=
o make it a relay policy first, and decide whether we want a softfork later=
.</p></body></html>
=20
------=_Part_96056_1392606999.1471428948508--