diff options
| author | Luke Dashjr <luke@dashjr.org> | 2016-08-17 04:40:34 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-17 04:42:03 +0000 |
| commit | 87858308f3c1c44d828134b256eeae4009f5ad0d (patch) | |
| tree | 4562b5f0030c0f9ccebd49bc6a71d625c0281d12 | |
| parent | d64ac3489bbb73fd8f57a63445ea4273fe441e62 (diff) | |
| download | pi-bitcoindev-87858308f3c1c44d828134b256eeae4009f5ad0d.tar.gz pi-bitcoindev-87858308f3c1c44d828134b256eeae4009f5ad0d.zip | |
Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
| -rw-r--r-- | 6c/340b4d84e4fd4577e542de1cb671d3f9e17d76 | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/6c/340b4d84e4fd4577e542de1cb671d3f9e17d76 b/6c/340b4d84e4fd4577e542de1cb671d3f9e17d76 new file mode 100644 index 000000000..ab1df6982 --- /dev/null +++ b/6c/340b4d84e4fd4577e542de1cb671d3f9e17d76 @@ -0,0 +1,83 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3397C919 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 17 Aug 2016 04:42:03 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (unknown [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id DD7F8203 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 17 Aug 2016 04:42:02 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id A981238A17C5; + Wed, 17 Aug 2016 04:40:36 +0000 (UTC) +X-Hashcash: 1:25:160817:bitcoin-dev@lists.linuxfoundation.org::tBcgTMsfEWnheJKk:fhfxj +X-Hashcash: 1:25:160817:jl2012@xbt.hk::CaPgBR5rXs=IuM1W:bmZBr +X-Hashcash: 1:25:160817:greg@xiph.org::RhUZeo9Zladd4otl:aGI0Z +X-Hashcash: 1:25:160817:roconnor@blockstream.io::mC4g/6n5yQrA28oS:15F6 +X-Hashcash: 1:25:160817:pete@petertodd.org::2JQ0UdN3+d5kh/mg:bsqjF +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, + Johnson Lau <jl2012@xbt.hk> +Date: Wed, 17 Aug 2016 04:40:34 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; ) +References: <1736097121.90204.1471369988809@privateemail.com> + <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com> + <976728541.94211.1471402973613@privateemail.com> +In-Reply-To: <976728541.94211.1471402973613@privateemail.com> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Message-Id: <201608170440.35767.luke@dashjr.org> +X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC + autolearn=no 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 04:42:03 -0000 + +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. + +I suspect most cases OP_IF would be used, you really want to accept any non- +zero value. For example, the HTLC script I posted on the list about not long +ago (OP_IF operates on the result from OP_SIZE). Counter-examples would be BIP +124, the examples in BIP 65 and BIP 112, but I note all of these could be just +as easily done without the explicit boolean being fed to the OP_IF (you'd need +an OP_DUP to keep the value, so it wouldn't reduce the byte-size). + +Of course, as long as we're talking about a softfork activating together with +segwit, and only having effect in segwit scripts... there's no reason we can't +add whatever opcodes we need so long as it gets done before 0.13.1. I suggest +OP_CASTTOBOOL and OP_DUPASBOOL would be two good candidates if we make OP_IF +stricter. There's also the possibility of adding an OP_RETAINIF which behaves +as the current OP_IF, except not popping the conditional value off the stack. +But perhaps this is getting too complicated for testing in time for segwit... + +Luke + |