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 3397C919 for ; 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 ; 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 To: bitcoin-dev@lists.linuxfoundation.org, Johnson Lau 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> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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