+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 688C840C

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>

+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 <jl2012@xbt.hk>

+In-Reply-To: <20181223042659.munrqfe4l6nff2ug@erisian.com.au>

+Date: Mon, 24 Dec 2018 00:33:48 +0800

+Content-Transfer-Encoding: quoted-printable

+Message-Id: <F445FD1D-52E2-41E4-8FBD-3419A6317CF6@xbt.hk>

+References: <87ftv3xerx.fsf@rustcorp.com.au>

+ <DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk>

+ <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au>

+ <20181214093002.p2nvfrlaycqblww3@erisian.com.au>

+ <F9FE2267-0BCB-4C67-9AE8-3285B7459D51@xbt.hk>

+ <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 <aj@erisian.com.au>

+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 <bitcoin-dev@lists.linuxfoundation.org>

+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 <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: Sun, 23 Dec 2018 16:34:19 -0000

+

+

+

+> On 23 Dec 2018, at 12:26 PM, Anthony Towns <aj@erisian.com.au> 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 <Bob> CHECKSIGVERIFY HASH160 <H> EQUALVERIFY CODESEP

+> ELSE <n> CLTV DROP

+> ENDIF

+> <Alice> CHECKSIG

+>=20

+> then compared to the taproot equivalent:

+>=20

+> P =3D muSig(Alice,Bob)

+> S1 =3D <Alice1> CHECKSIGVERIFY <Bob> CHECKSIGVERIFY HASH160 <H> EQUAL

+> S2 =3D <Alice2> CHECKSIGVERIFY <n> 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 <n> 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?

+

+

+