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 0EB2F15 for ; Sun, 23 Dec 2018 04:27:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BFE8A8 for ; Sun, 23 Dec 2018 04:27:18 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1gavLz-0001zi-It; Sun, 23 Dec 2018 14:27:05 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sun, 23 Dec 2018 14:26:59 +1000 Date: Sun, 23 Dec 2018 14:26:59 +1000 From: Anthony Towns To: Johnson Lau Message-ID: <20181223042659.munrqfe4l6nff2ug@erisian.com.au> References: <87ftv3xerx.fsf@rustcorp.com.au> <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au> <20181214093002.p2nvfrlaycqblww3@erisian.com.au> <87mup4hmq5.fsf@rustcorp.com.au> <2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk> <87y38jn5z8.fsf@rustcorp.com.au> <73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 23 Dec 2018 18:43:54 +0000 Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT 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: Sun, 23 Dec 2018 04:27:19 -0000 On Sat, Dec 22, 2018 at 02:54:42AM +0800, Johnson Lau wrote: > The question I would like to ask is: is OP_CODESEPARATOR useful under taproot? Generally speaking, CODESEPARATOR is useful only with conditional opcodes (OP_IF etc), and conditional opcodes are mostly replaced by merklized scripts. I am not sure how much usability is left with CODESEPARATOR If you don't have conditionals, then I think committing to the (masked) script gives you everything you could do with codeseparator. If you don't commit to the (masked) script, don't have conditionals, and don't have codeseparator, then I don't think you can make a signature distinguish which alternative script it's intending to sign; but you can just give each alternative script in the MAST a slight variation of the key and that seems good enough. OTOH, I think for (roughly) the example you gave: DEPTH 3 EQUAL IF CHECKSIGVERIFY HASH160 EQUALVERIFY CODESEP ELSE CLTV DROP ENDIF CHECKSIG then compared to the taproot equivalent: P = muSig(Alice,Bob) S1 = CHECKSIGVERIFY CHECKSIGVERIFY HASH160 EQUAL S2 = CHECKSIGVERIFY CLTV the IF+CODESEP approach is actually cheaper (lighter weight) if you're mostly (>2/3rds of the time) taking the S1 branch. This is because the "DEPTH 3 EQUAL IF/ELSE/ENDIF CODESEP CLTV DROP" overhead is less than the 32B overhead to choose a merkle branch). (That said, I'm not sure what Alice's signature in the S1 branch actually achieves in that script; and without that in S1, the taproot approach is cheaper all the time. Scriptless scripts would be cheaper still) > If no one needs CODESEPARATOR, we might just disable it, and makes the validation code a bit simpler Since it only affects the behaviour of the checkdls (checksig) operators, even if it was disabled, it could be re-enabled fairly easily in a new script subversion if needed (ie, it could be re-added when upgrading witness version 1 from script version 0 to 1). Cheers, aj