path: root/b7/ae3c43d87d5d1bde9a12bd4e539a2a61f9c43b

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EDF7B6C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 20:59:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31B26F4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 20:59:16 +0000 (UTC)
Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com
	[209.85.208.52]) (authenticated bits=0)
	(User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4OKxEm5020425
	(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 16:59:15 -0400
Received: by mail-ed1-f52.google.com with SMTP id a8so16058425edx.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 13:59:15 -0700 (PDT)
X-Gm-Message-State: APjAAAVzfYg+iypldIdwOg9FfmhSPiV3Y0z8fV8A558TVe3dosAsnk8u
	zvsedbQtCLADdaZFPv+2uuuMBp6s+bMLioVpSiU=
X-Google-Smtp-Source: APXvYqy58/fNSBTKHimBY2HWHj3hAKE7orAVmGS1K9pT8rOOsHHu13Tp920srNlxNDSwgzcLST8TVSPk+xZeklZpmds=
X-Received: by 2002:a17:906:5a08:: with SMTP id
	p8mr67168122ejq.276.1558731554297; 
	Fri, 24 May 2019 13:59:14 -0700 (PDT)
MIME-Version: 1.0
References: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk>
In-Reply-To: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 24 May 2019 13:59:03 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhsk_4+C3dROGhBZqjmiqmOO+hGYR9qawbJ9MDW0so4=Q@mail.gmail.com>
Message-ID: <CAD5xwhhsk_4+C3dROGhBZqjmiqmOO+hGYR9qawbJ9MDW0so4=Q@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009820cc0589a87822"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED 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: Sat, 25 May 2019 12:07:05 +0000
Subject: Re: [bitcoin-dev] Safety of committing only to transaction outputs
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: Fri, 24 May 2019 20:59:18 -0000

--0000000000009820cc0589a87822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Johnson,

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.

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.

There are also other mechanisms that can improve the safety. Proposed below=
:

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.

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.

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, May 24, 2019 at 7:40 AM Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a meta-discussion for any approach that allows the witness
> committing to only transaction outputs, but not inputs.
>
> We can already do the following things with the existing bitcoin script
> system:
> * commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with
> optional SIGHASH_ANYONECANPAY
> * commit to only inputs but not outputs: SIGHASH_NONE with optional
> SIGHASH_ANYONECANPAY
> * not commit to any input nor output: not using any sigop; using a trivia=
l
> private key; using the SIGHASH_SINGLE bug in legacy script
>
> The last one is clearly unsafe as any relay/mining node may redirect the
> payment to any output it chooses. The witness/scriptSig is also replayabl=
e,
> so any future payment to this script will likely be swept immediately
>
> SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but th=
e
> signature is not replayable
>
> But it=E2=80=99s quite obvious that not committing to outputs are inheren=
tly
> insecure
>
> The existing system doesn=E2=80=99t allow committing only to outputs, and=
 we now
> have 3 active proposals for this function:
>
> 1. CAT and CHECKSIGFROMSTACK (CSFS):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.h=
tml
> 2. ANYPREVOUT (aka NOINPUT):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.h=
tml
> 3. CHECKOUTPUTSHASHVERIFY (COHV):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.h=
tml
>
> With outputs committed, redirecting payment is not possible. On the other
> hand, not committing to any input means the witness is replayable without
> the consent of address owner. Whether replayability is acceptable is
> subject to controversy, but the ANYPREVOUT proposal fixes this by requiri=
ng
> a chaperone signature that commits to input. However, if the rationale fo=
r
> chaperone signature stands, it should be applicable to all proposals list=
ed
> above.
>
> A more generic approach is to always require a =E2=80=9Csafe" signature t=
hat
> commits to at least one input. However, this interacts poorly with the
> "unknown public key type=E2=80=9D upgrade path described in bip-tapscript=
 (
> https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki),
> since it=E2=80=99d be a hardfork to turn an =E2=80=9Cunknown type sig=E2=
=80=9D into a =E2=80=9Csafe sig=E2=80=9D.
> But we could still use a new =E2=80=9Cleaf version=E2=80=9D every time we=
 introduce new
> sighash types, so we could have a new definition for =E2=80=9Csafe sig=E2=
=80=9D. I expect
> this would be a rare event and it won=E2=80=99t consume more than a coupl=
e leaf
> versions. By the way, customised sighash policies could be done with
> CAT/CSFS.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000009820cc0589a87822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Johnson,</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">As note=
d 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 co=
ntrol tree.</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">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"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">There are also other mechanisms that c=
an improve the safety. Proposed below:</div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000">OP_CHECKINPUTSHASHVERIFY -- al=
low checking that the hash of the inputs is a particular value. The top-lev=
el 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></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">OP_CHECK=
FEEVERIFY -- allowing an explicit commitment to the exact amount of fee lim=
its replay to txns which were funded with the exact amount of the prior. If=
 there&#39;s a mismatch, an alternative branch can be used. This is a gener=
ally useful mechanism, but means that transactions using it must have all i=
nputs/outputs set.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Best,</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">Jeremy<br></div><div><div dir=3D"ltr" =
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"lt=
r">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@Jer=
emyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"><=
/a></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Fri, May 24, 2019 at 7:40 AM Johnson Lau via bi=
tcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div style=3D"overflow-wrap: break-word;">=
This is a meta-discussion for any approach that allows the witness committi=
ng to only transaction outputs, but not inputs.<div><br></div><div>We can a=
lready do the following things with the existing bitcoin script system:</di=
v><div>* commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, =
with optional SIGHASH_ANYONECANPAY</div><div>* commit to only inputs but no=
t outputs: SIGHASH_NONE with optional SIGHASH_ANYONECANPAY</div><div>* not =
commit to any input nor output: not using any sigop; using a trivial privat=
e key; using the SIGHASH_SINGLE bug in legacy script</div><div><br></div><d=
iv>The last one is clearly unsafe as any relay/mining node may redirect the=
 payment to any output it chooses. The witness/scriptSig is also replayable=
, so any future payment to this script will likely be swept immediately</di=
v><div><br></div><div>SIGHASH_NONE with ANYONECANPAY also allows redirectio=
n of payment, but the signature is not replayable</div><div><br></div><div>=
But it=E2=80=99s quite obvious that not committing to outputs are inherentl=
y insecure</div><div><br></div><div>The existing system doesn=E2=80=99t all=
ow committing only to outputs, and we now have 3 active proposals for this =
function:</div><div><br></div><div>1. CAT and CHECKSIGFROMSTACK (CSFS):=C2=
=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-=
May/016946.html" target=3D"_blank">https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2019-May/016946.html</a></div><div>2. ANYPREVOUT (aka NOINP=
UT):=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-May/016929.html" target=3D"_blank">https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2019-May/016929.html</a></div><div>3. CHECKOUTPUTSHA=
SHVERIFY (COHV):=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2019-May/016934.html" target=3D"_blank">https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2019-May/016934.html</a></div><div><br><=
/div><div>With outputs committed, redirecting payment is not possible. On t=
he other hand, not committing to any input means the witness is replayable =
without the consent of address owner. Whether replayability is acceptable i=
s subject to controversy, but the ANYPREVOUT proposal fixes this by requiri=
ng a chaperone signature that commits to input. However, if the rationale f=
or chaperone signature stands, it should be applicable to all proposals lis=
ted above.</div><div><br></div><div>A more generic approach is to always re=
quire a =E2=80=9Csafe&quot; signature that commits to at least one input. H=
owever, this interacts poorly with the &quot;unknown public key type=E2=80=
=9D upgrade path described in bip-tapscript (<a href=3D"https://github.com/=
sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki" target=3D"_blank">https=
://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki</a>), sinc=
e it=E2=80=99d be a hardfork to turn an =E2=80=9Cunknown type sig=E2=80=9D =
into a =E2=80=9Csafe sig=E2=80=9D. But we could still use a new =E2=80=9Cle=
af version=E2=80=9D every time we introduce new sighash types, so we could =
have a new definition for =E2=80=9Csafe sig=E2=80=9D. I expect this would b=
e a rare event and it won=E2=80=99t consume more than a couple leaf version=
s. By the way, customised sighash policies could be done with CAT/CSFS.</di=
v></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000009820cc0589a87822--