Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 688C840C for ; Sun, 23 Dec 2018 16:34:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B62BDA8 for ; Sun, 23 Dec 2018 16:34:18 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545582839; cv=none; d=zoho.com; s=zohoarc; b=dLNYZ9BaA4Ye4R0pgLP1zbXVbMYLqT6NUkV/VYQdWuiSoayBXXfzoAxQhsGly6+319rOFYlXAEW3pba2XKw98d3hKvgY0bdsp/bSKaFUWN8HKCb/I7wTTcHpWgCNbvHC8iWjzJdZyy4GjWYvkQJLZIAz8TpIStyG4ks8vTQPweU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545582839; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=sLuARgf6icZJ9h2EU2goD5cav79/QYCdjOfpyKXuzLI=; b=goaow0MsBIPIMCE+2++TU+Fpt8GpDwJs+2ZJySQxbc9i0+bvm7+0n5/9PLmMKQ5zsd8b8qYGc7tIkAinU7FlQdVFfPtk5E/n0SMYSBkjl4kHLDBurKzl/1qbFBX/ng08TcL4XTRtYKlZ0TYEXk9y8W4DI1PfooMBKjOrGqJ0aC4= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1545582835711209.37520501634015; Sun, 23 Dec 2018 08:33:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Johnson Lau In-Reply-To: <20181223042659.munrqfe4l6nff2ug@erisian.com.au> Date: Mon, 24 Dec 2018 00:33:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20181223042659.munrqfe4l6nff2ug@erisian.com.au> To: Anthony Towns X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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 16:34:19 -0000 > On 23 Dec 2018, at 12:26 PM, Anthony Towns wrote: >=20 > 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 >=20 > If you don't have conditionals, then I think committing to the = (masked) > script gives you everything you could do with codeseparator. I don=E2=80=99t think CODESEPARATOR is useful without conditionals. By = useful I mean making a script more compact >=20 > 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. You can and should always use a different in different branch. If this = best practice is always followed, committing to masked script is not = necessary >=20 > OTOH, I think for (roughly) the example you gave: >=20 > DEPTH 3 EQUAL > IF CHECKSIGVERIFY HASH160 EQUALVERIFY CODESEP > ELSE CLTV DROP > ENDIF > CHECKSIG >=20 > then compared to the taproot equivalent: >=20 > P =3D muSig(Alice,Bob) > S1 =3D CHECKSIGVERIFY CHECKSIGVERIFY HASH160 EQUAL > S2 =3D CHECKSIGVERIFY CLTV >=20 > 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). >=20 > (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) >=20 >> If no one needs CODESEPARATOR, we might just disable it, and makes = the validation code a bit simpler >=20 > 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). >=20 > Cheers, > aj >=20 Yes, I don=E2=80=99t think it needs Alice signature in S1 at all. So the = original example doesn=E2=80=99t even need CODESEPARATOR at all.=20 Could anyone propose a better use case of CODESEPARATOR?