From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <64A86A3A-4633-4BE2-AE09-30BD136BCC2D@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Thu, 22 Nov 2018 22:28:35 +0800
In-Reply-To: <CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
	<CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Precedence: list


--Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

With MAST in taproot, OP_IF etc become mostly redundant, with worse =
privacy. To maximise fungibility, we should encourage people to use =
MAST, instead of improve the functionality of OP_IF and further =
complicate the protocol.


> On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>=20
> Hopefully my comment is on-topic for this thread:
>=20
> Given that we want to move away from OP_CODESEPARATOR, because each =
call to this operation effectively takes O(script-size) time, we need a =
replacement for the functionality it currently provides.  While perhaps =
the original motivation for OP_CODESEPARTOR is surrounded in mystery, it =
currently can be used (or perhaps abused) for the task of creating =
signature that covers, not only which input is being signed, but which =
specific branch within that input Script code is being signed for.
>=20
> For example, one can place an OP_CODESEPARATOR within each branch of =
an IF block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG =
operation.  By doing so, signatures created for one clause cannot be =
used as signatures for another clause.  Since different clauses in =
Bitcoin Script may be enforcing different conditions (such as different =
time-locks, hash-locks, etc), it is useful to be able to sign in such a =
way that your signature is only valid when the conditions for a =
particular branch are satisfied.  In complex Scripts, it may not be =
practical or possible to use different public keys for every different =
clause. (In practice, you will be able to get away with fewer =
OP_CODESEPARATORS than one in every IF block).
>=20
> One suggestion I heard (I think I heard it from Pieter) to achieve the =
above is to add an internal counter that increments on every control =
flow operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the =
signature cover the value of this counter.  Equivalently we divide every =
Bitcoin Script program into blocks deliminated by these control flow =
operator and have the signature cover the index of the block that the =
OP_CHECKSIG occurs within.  More specifically, we will want a SigHash =
flag to enables/disable the signature covering this counter.
>=20
> There are many different ways one might go about replacing the =
remaining useful behaviour of OP_CODESEPARATOR than the one I gave =
above. I would be happy with any solution.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">With =
MAST in taproot, OP_IF etc become mostly redundant, with worse privacy. =
To maximise fungibility, we should encourage people to use MAST, instead =
of improve the functionality of OP_IF and further complicate the =
protocol.<div class=3D""><br class=3D""></div><div class=3D""><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 22 =
Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On =
Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">So my question is =
whether anyone can see ways in which this introduces<br class=3D"">
redundant flexibility, or misses obvious use cases?<br =
class=3D""></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">Hopefully my comment is on-topic for this thread:</div><div =
class=3D""><br class=3D""></div><div class=3D"">Given that we want to =
move away from OP_CODESEPARATOR, because each call to this operation =
effectively takes O(script-size) time, we need a replacement for the =
functionality it currently provides.&nbsp; While perhaps the original =
motivation for OP_CODESEPARTOR is surrounded in mystery, it currently =
can be used (or perhaps abused) for the task of creating signature that =
covers, not only which input is being signed, but which specific branch =
within that input Script code is being signed for.</div><div =
class=3D""><br class=3D""></div><div class=3D"">For example, one can =
place an OP_CODESEPARATOR within each branch of an IF block, or by =
placing an OP_CODESEPARATOR before each OP_CHECKSIG operation.&nbsp; By =
doing so, signatures created for one clause cannot be used as signatures =
for another clause.&nbsp; Since different clauses in Bitcoin Script may =
be enforcing different conditions (such as different time-locks, =
hash-locks, etc), it is useful to be able to sign in such a way that =
your signature is only valid when the conditions for a particular branch =
are satisfied.&nbsp; In complex Scripts, it may not be practical or =
possible to use different public keys for every different clause. (In =
practice, you will be able to get away with fewer OP_CODESEPARATORS than =
one in every IF block).<br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">One suggestion I heard (I think I heard =
it from Pieter) to achieve the above is to add an internal counter that =
increments on every control flow operator, OP_IF, OP_NOTIF, OP_ELSE, =
OP_ENDIF, and have the signature cover the value of this counter.&nbsp; =
Equivalently we divide every Bitcoin Script program into blocks =
deliminated by these control flow operator and have the signature cover =
the index of the block that the OP_CHECKSIG occurs within.&nbsp; More =
specifically, we will want a SigHash flag to enables/disable the =
signature covering this counter.<br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">There are many different ways one might =
go about replacing the remaining useful behaviour of OP_CODESEPARATOR =
than the one I gave above. I would be happy with any solution.<br =
class=3D""></div></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469--