path: root/f1/aaf2dc64760d341df313e95681dc1092fe382e

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 0B371FCB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 20:36:20 +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 F2290F4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 20:36:18 +0000 (UTC)
Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com
	[209.85.208.46]) (authenticated bits=0)
	(User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4OKaGHQ005645
	(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 16:36:17 -0400
Received: by mail-ed1-f46.google.com with SMTP id w33so12613818edb.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 13:36:17 -0700 (PDT)
X-Gm-Message-State: APjAAAVh/qQK8t+xe0RZTZjbXVFSLX8vWTqO1j/HMzYCIPbYgtJklvdG
	0DSy4eM11vC7Ab2VDAlLKIQGCZGBwSN3SdxJM7k=
X-Google-Smtp-Source: APXvYqwQ1Nyzdg1VVDKuBowtI5nXswnOI/nji0E8u3kiTQGcFfHVCQpMHL8uR3u1iEZ9eYSEZmE4d67vBFk3psjD+U0=
X-Received: by 2002:a17:906:7cd2:: with SMTP id
	h18mr47941176ejp.267.1558730175901; 
	Fri, 24 May 2019 13:36:15 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<52AFAB05-040B-4310-9328-96E14A779D60@xbt.hk>
In-Reply-To: <52AFAB05-040B-4310-9328-96E14A779D60@xbt.hk>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 24 May 2019 13:36:03 -0700
X-Gmail-Original-Message-ID: <CAD5xwhj58kq-HJTKKpq8VaXoWcw-Oec=kRhbd9SdxpE83n6Mew@mail.gmail.com>
Message-ID: <CAD5xwhj58kq-HJTKKpq8VaXoWcw-Oec=kRhbd9SdxpE83n6Mew@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary="0000000000006f77070589a826b9"
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:00 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
	proposal
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:36:20 -0000

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

Hi Johnson,

Thanks for the review. I do agree that OP_COSHV (note the pluralization --
it would also be possible to do a OP_COHV <index> <hash> to do specific
outputs).

I think the point of OP_COSHV is that something like ANYPREVOUT is much
more controversial. OP_COSHV is a subset by design. The IF on ANYPREVOUT is
substantial, discussion I've seen shows that the safety of ANYPREVOUT is
far from fully agreed. (I'll respond to your other email on the subject
too). OP_COSHV is also proposed specifically as a congestion control
mechanism, and so keeping it very easy to verify and minimal data
(optimizations allow reducing it to just OP_COSHV with no 32 byte argument)
suggest this approach is preferable.

In an earlier version, rather than have it be the first input restriction,
I had implemented it an an only one input restriction. This makes it easier
to work with SIGHASH_SINGLE. This works by having the PrecomputedData have
a atomic test_flag. However I felt that the statefulness between
verifications was not great and so I simplified it.

There actually is a reason to require minimal push -- maybe we can change
the rule to be non-minimal pushes are ignored, because we can later extend
it with a different rule. This seems a little error prone. There's also no
reason to not just treat OP_COSHV as a pushdata 32 itself, and drop the
extra byte if we don't care about versioning later.

Requiring a signature actually makes COSHV less useful. So I'm against that
-- such a signature prevents using OP_COSHV for non-interactive
setups/uncoordinated setups where the txids are unstable. It also makes
building the trees more expensive. If you want this feature, a better thing
to do would be to always tweak leaf nodes of the tx tree entropy so that
it's unique per key and doesn't impose extra data at every node, only the
leafs of the expansion tree.


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


On Fri, May 24, 2019 at 12:13 PM Johnson Lau <jl2012@xbt.hk> wrote:

> Functionally, COHV is a proper subset of ANYPREVOUT (NOINPUT). The only
> justification to do both is better space efficiency when making covenant.
>
> With eltoo as a clear usecase of ANYPREVOUT, I=E2=80=99m not sure if we r=
eally
> want a very restricted opcode like COHV. But these are my comments, anywa=
y:
>
> 1. The =E2=80=9Cone input=E2=80=9D rule could be relaxed to =E2=80=9Cfirs=
t input=E2=80=9D rule. This
> allows adding more inputs as fees, as an alternative to CPFP. In case the
> value is insufficient to pay the required outputs, it is also possible to
> rescue the UTXO by adding more inputs.
>
> 2. While there is no reason to use non-minimal push, there is neither a
> reason to require minimal push. Since minimal push is never a consensus
> rule, COHV shouldn=E2=80=99t be a special case.
>
> 3. As I suggested in a different post (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.h=
tml),
> the argument for requiring a prevout binding signature may also be
> applicable to COHV
>
> On 21 May 2019, at 4:58 AM, Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello bitcoin-devs,
>
> Below is a link to a BIP Draft for a new opcode,
> OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless
> congestion control techniques via a rudimentary, limited form of covenant
> which does not bear the same technical and social risks of prior covenant
> designs.
>
> Congestion control allows Bitcoin users to confirm payments to many users
> in a single transaction without creating the UTXO on-chain until a later
> time. This therefore improves the throughput of confirmed payments, at th=
e
> expense of latency on spendability and increased average block space
> utilization. The BIP covers this use case in detail, and a few other use
> cases lightly.
>
> The BIP draft is here:
>
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-co=
shv.mediawiki
>
> The BIP proposes to deploy the change simultaneously with Taproot as an
> OPSUCCESS, but it could be deployed separately if needed.
>
> An initial reference implementation of the consensus changes and  tests
> which demonstrate how to use it for basic congestion control is available
> at https://github.com/JeremyRubin/bitcoin/tree/congestion-control.  The
> changes are about 74 lines of code on top of sipa's Taproot reference
> implementation.
>
> Best regards,
>
> Jeremy Rubin
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

--0000000000006f77070589a826b9
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">Thanks =
for the review. I do agree that OP_COSHV (note the pluralization -- it woul=
d also be possible to do a OP_COHV &lt;index&gt; &lt;hash&gt; to do specifi=
c outputs). <br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">I think the point of OP_COSHV is that something like=
 ANYPREVOUT is much more controversial. OP_COSHV is a subset by design. The=
 IF on ANYPREVOUT is substantial, discussion I&#39;ve seen shows that the s=
afety of ANYPREVOUT is far from fully agreed. (I&#39;ll respond to your oth=
er email on the subject too). OP_COSHV is also proposed specifically as a c=
ongestion control mechanism, and so keeping it very easy to verify and mini=
mal data (optimizations allow reducing it to just OP_COSHV with no 32 byte =
argument) suggest this approach is preferable.<br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">In an earlier vers=
ion, rather than have it be the first input restriction, I had implemented =
it an an only one input restriction. This makes it easier to work with SIGH=
ASH_SINGLE. This works by having the PrecomputedData have a atomic test_fla=
g. However I felt that the statefulness between verifications was not great=
 and so I simplified it.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">There actually is a reason to require minima=
l push -- maybe we can change the rule to be non-minimal pushes are ignored=
, because we can later extend it with a different rule. This seems a little=
 error prone. There&#39;s also no reason to not just treat OP_COSHV as a pu=
shdata 32 itself, and drop the extra byte if we don&#39;t care about versio=
ning later.</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">Requiring a signature actually makes COSHV less useful. S=
o I&#39;m against that -- such a signature prevents using OP_COSHV for non-=
interactive setups/uncoordinated setups where the txids are unstable. It al=
so makes building the trees more expensive. If you want this feature, a bet=
ter thing to do would be to always tweak leaf nodes of the tx tree entropy =
so that it&#39;s unique per key and doesn&#39;t impose extra data at every =
node, only the leafs of the expansion tree.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br clear=3D"all"></div><=
div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sign=
ature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" t=
arget=3D"_blank">@JeremyRubin</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"ltr" class=3D"gmail_attr">On Fri, May 24, 2019 at 12:13=
 PM Johnson Lau &lt;<a href=3D"mailto:jl2012@xbt.hk">jl2012@xbt.hk</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div styl=
e=3D"overflow-wrap: break-word;">Functionally, COHV is a proper subset of A=
NYPREVOUT (NOINPUT). The only justification to do both is better space effi=
ciency when making covenant.<div><br></div><div>With eltoo as a clear useca=
se of ANYPREVOUT, I=E2=80=99m not sure if we really want a very restricted =
opcode like COHV. But these are my comments, anyway:</div><div><br></div><d=
iv>1. The =E2=80=9Cone input=E2=80=9D rule could be relaxed to =E2=80=9Cfir=
st input=E2=80=9D rule. This allows adding more inputs as fees, as an alter=
native to CPFP. In case the value is insufficient to pay the required outpu=
ts, it is also possible to rescue the UTXO by adding more inputs.</div><div=
><br></div><div>2. While there is no reason to use non-minimal push, there =
is neither a reason to require minimal push. Since minimal push is never a =
consensus rule, COHV shouldn=E2=80=99t be a special case.</div><div><br></d=
iv><div>3. As I suggested in a different post (<a href=3D"https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.html" target=3D"_bla=
nk">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963=
.html</a>), the argument for requiring a prevout binding signature may also=
 be applicable to COHV<br><div><br><blockquote type=3D"cite"><div>On 21 May=
 2019, at 4:58 AM, Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:</div><br class=3D"gmail-m_-3709645309908580911Apple=
-interchange-newline"><div><div dir=3D"ltr"><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small">Hello bitcoi=
n-devs,<br>
<br>Below is a link to a BIP Draft for a new opcode, OP_CHECKOUTPUTSHASHVER=
IFY. This opcode enables an easy-to-use trustless congestion control techni=
ques via a rudimentary, limited form of covenant which does not bear the sa=
me technical and social risks of prior covenant designs.<br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small">Congestion control allows Bitcoin us=
ers to confirm payments to many users in a single transaction without creat=
ing the UTXO on-chain until a later time. This therefore improves the throu=
ghput of confirmed payments, at the expense of latency on spendability and =
increased average block space utilization. The BIP covers this use case in =
detail, and a few other use cases lightly.<br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><br>
The BIP draft is here:</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small"><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><a href=
=3D"https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-=
coshv.mediawiki" target=3D"_blank">https://github.com/JeremyRubin/bips/blob=
/op-checkoutputshashverify/bip-coshv.mediawiki</a></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small">=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small">The BIP proposes to deploy the change simultan=
eously with Taproot as an OPSUCCESS, but it could be deployed separately if=
 needed.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small">An initia=
l reference implementation of the consensus changes and=C2=A0 tests which d=
emonstrate how to use it for basic congestion control is available at <a hr=
ef=3D"https://github.com/JeremyRubin/bitcoin/tree/congestion-control" targe=
t=3D"_blank">https://github.com/JeremyRubin/bitcoin/tree/congestion-control=
</a>.=C2=A0 The changes are about 74 lines of code on top of sipa&#39;s Tap=
root reference implementation.<br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small">Best regards,</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall">Jeremy Rubin<br></div></div></div>
_______________________________________________<br>bitcoin-dev mailing list=
<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></block=
quote></div><br></div></div></blockquote></div>

--0000000000006f77070589a826b9--