diff options
| author | Johnson Lau <jl2012@xbt.hk> | 2016-08-17 06:15:48 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-17 10:15:52 +0000 |
| commit | 50c95a3d7cce441a4838f6f6c931391fa87e2713 (patch) | |
| tree | 545752ce4173f8b768846d149a823bcdc3fbf99a | |
| parent | 1799c2024ac01e783f03b5e06f17fca3d064c807 (diff) | |
| download | pi-bitcoindev-50c95a3d7cce441a4838f6f6c931391fa87e2713.tar.gz pi-bitcoindev-50c95a3d7cce441a4838f6f6c931391fa87e2713.zip | |
Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
| -rw-r--r-- | b7/6cc585076f2470103be9c6ce5d6bdb88850b55 | 121 |
1 files changed, 121 insertions, 0 deletions
diff --git a/b7/6cc585076f2470103be9c6ce5d6bdb88850b55 b/b7/6cc585076f2470103be9c6ce5d6bdb88850b55 new file mode 100644 index 000000000..101f7ea8d --- /dev/null +++ b/b7/6cc585076f2470103be9c6ce5d6bdb88850b55 @@ -0,0 +1,121 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id A4D9699A + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <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" +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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>> On August 17, 2016 at 12:40 AM Luke Dashjr= + <luke@dashjr.org> wrote:<br>> <br>> <br>> On Wednesday= +, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:<br>> &#= +62; To completely replicate the original behaviour, one may use:<br>> &= +#62; "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {i= +f script}<br>> > ELSE DROP {else script} ENDIF"<br>> <br>&#= +62; This is much uglier than expected. IMO if that's the best workaroun= +d for the <br>> current behaviour, people should just use "OP_1 OP_= +EQUAL OP_IF" when/if they <br>> 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, "= +;OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF",= + 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: <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-- + |