From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <EB79DBDB-9C29-4699-9A06-27D1A2896661@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 25 May 2019 15:53:34 +0800
In-Reply-To: <CAD5xwhhsk_4+C3dROGhBZqjmiqmOO+hGYR9qawbJ9MDW0so4=Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
References: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk>
	<CAD5xwhhsk_4+C3dROGhBZqjmiqmOO+hGYR9qawbJ9MDW0so4=Q@mail.gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safety of committing only to transaction outputs
Precedence: list


--Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 25 May 2019, at 4:59 AM, Jeremy <jlrubin@mit.edu> wrote:
>=20
> Hi Johnson,
>=20
> As noted on the other thread, witness replay-ability can be helped by =
salting the taproot key or the taproot leaf script at the last stage of =
a congestion control tree.
>=20

The salt will be published when it is first spent. Salting won=E2=80=99t =
help if the address is reused.

> I also think that chaperone signatures should be opt-in; there are =
cases where we may not want them. OP_COSHV is compatible with an =
additional checksig operation.
>=20
> There are also other mechanisms that can improve the safety. Proposed =
below:
>=20
> OP_CHECKINPUTSHASHVERIFY -- allow checking that the hash of the inputs =
is a particular value. The top-level of a congestion control tree can =
check that the inputs match the desired inputs for that spend, and =
default to requiring N of N otherwise. This is replay proof! This is =
useful for other applications too.

It is circular dependent: the script has to commit to the txid, and the =
txid is a function of script


>=20
> OP_CHECKFEEVERIFY -- allowing an explicit commitment to the exact =
amount of fee limits replay to txns which were funded with the exact =
amount of the prior. If there's a mismatch, an alternative branch can be =
used. This is a generally useful mechanism, but means that transactions =
using it must have all inputs/outputs set.
>=20

This restricts replayability to input with same value, but is still =
replay-able, just like ANYPREVOUT committing to the input value


> Best,
>=20
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin> =
<https://twitter.com/JeremyRubin>

--Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 25 May 2019, at 4:59 AM, Jeremy &lt;<a =
href=3D"mailto:jlrubin@mit.edu" class=3D"">jlrubin@mit.edu</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_default" style=3D"font-family: =
arial, helvetica, sans-serif; font-size: small;">Hi Johnson,</div><div =
class=3D"gmail_default" style=3D"font-family: arial, helvetica, =
sans-serif; font-size: small;"><br class=3D""></div><div =
class=3D"gmail_default" style=3D"font-family: arial, helvetica, =
sans-serif; font-size: small;">As noted on the other thread, witness =
replay-ability can be helped by salting the taproot key or the taproot =
leaf script at the last stage of a congestion control tree.</div><div =
class=3D"gmail_default" style=3D"font-family: arial, helvetica, =
sans-serif; font-size: small;"><br =
class=3D""></div></div></div></blockquote><div><br =
class=3D""></div><div>The salt will be published when it is first spent. =
Salting won=E2=80=99t help if the address is reused.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_default" style=3D"font-family: =
arial, helvetica, sans-serif; font-size: small;">I also think that =
chaperone signatures should be opt-in; there are cases where we may not =
want them. OP_COSHV is compatible with an additional checksig =
operation.</div><div class=3D"gmail_default" style=3D"font-family: =
arial, helvetica, sans-serif; font-size: small;"><br class=3D""></div><div=
 class=3D"gmail_default" style=3D"font-family: arial, helvetica, =
sans-serif; font-size: small;">There are also other mechanisms that can =
improve the safety. Proposed below:</div><div class=3D"gmail_default" =
style=3D"font-family: arial, helvetica, sans-serif; font-size: =
small;"><br class=3D""></div><div class=3D"gmail_default" =
style=3D"font-family: arial, helvetica, sans-serif; font-size: =
small;">OP_CHECKINPUTSHASHVERIFY -- allow checking that the hash of the =
inputs is a particular value. The top-level of a congestion control tree =
can check that the inputs match the desired inputs for that spend, and =
default to requiring N of N otherwise. This is replay proof! This is =
useful for other applications too.<br =
class=3D""></div></div></div></blockquote><div><br =
class=3D""></div><div>It is circular dependent: the script has to commit =
to the txid, and the txid is a function of script</div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_default" =
style=3D"font-family: arial, helvetica, sans-serif; font-size: =
small;"><br class=3D""></div><div class=3D"gmail_default" =
style=3D"font-family: arial, helvetica, sans-serif; font-size: =
small;">OP_CHECKFEEVERIFY -- allowing an explicit commitment to the =
exact amount of fee limits replay to txns which were funded with the =
exact amount of the prior. If there's a mismatch, an alternative branch =
can be used. This is a generally useful mechanism, but means that =
transactions using it must have all inputs/outputs set.</div><div =
class=3D"gmail_default" style=3D"font-family: arial, helvetica, =
sans-serif; font-size: small;"><br =
class=3D""></div></div></div></blockquote><div><br =
class=3D""></div><div>This restricts replayability to input with same =
value, but is still replay-able, just like ANYPREVOUT committing to the =
input value</div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_default" style=3D"font-family: arial, helvetica, =
sans-serif; font-size: small;">Best,</div><div class=3D"gmail_default" =
style=3D"font-family: arial, helvetica, sans-serif; font-size: =
small;"><br class=3D""></div><div class=3D"gmail_default" =
style=3D"font-family: arial, helvetica, sans-serif; font-size: =
small;">Jeremy<br class=3D""></div><div class=3D""><div dir=3D"ltr" =
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr" class=3D"">--<br class=3D""><a =
href=3D"https://twitter.com/JeremyRubin" target=3D"_blank" =
class=3D"">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" =
target=3D"_blank" =
class=3D""></a></div></div></div></div></div></blockquote></div><br =
class=3D""></body></html>=

--Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9--