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>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Precedence: list



> 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?