path: root/1c/0058ea1e42f655cabd38e36c92fcc1e9cf0213

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 54E449F0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 May 2019 01:47:28 +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 2CC7D6C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 May 2019 01:47:26 +0000 (UTC)
Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com
	[209.85.208.49]) (authenticated bits=0)
	(User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4M1lOa3029371
	(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 May 2019 21:47:25 -0400
Received: by mail-ed1-f49.google.com with SMTP id w37so1253797edw.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 May 2019 18:47:25 -0700 (PDT)
X-Gm-Message-State: APjAAAWSvUjy8ek4Q51glOPWeenI+hza0NiLEvFWQUf+YUqLz3rkl82r
	LBnuAiFdv1UZKW+z2QBQEEzFKQk2v7WtR084Tnc=
X-Google-Smtp-Source: APXvYqxM6fyOrAHHfcnMNxF1Gw17KLGnfm+1dyIeWuhe4QMUenxKal7oylKg/9vGC/QLwZe2FmfEvYgAhuqo3RG8rQQ=
X-Received: by 2002:a50:ba1d:: with SMTP id g29mr32375035edc.298.1558489644260;
	Tue, 21 May 2019 18:47:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<80353196-0f32-0e7b-d048-bd870e30029c@mattcorallo.com>
In-Reply-To: <80353196-0f32-0e7b-d048-bd870e30029c@mattcorallo.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 21 May 2019 18:47:11 -0700
X-Gmail-Original-Message-ID: <CAD5xwhh4McBah1yr0X5sDyto+0Q8XVOzg7Jq9Z=rXRyoS=n6gg@mail.gmail.com>
Message-ID: <CAD5xwhh4McBah1yr0X5sDyto+0Q8XVOzg7Jq9Z=rXRyoS=n6gg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="000000000000a1e2f20589702583"
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: Wed, 22 May 2019 13:30:30 +0000
Cc: Bitcoin development mailing list <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: Wed, 22 May 2019 01:47:28 -0000

--000000000000a1e2f20589702583
Content-Type: text/plain; charset="UTF-8"

I agree a little bit, but I think that logic is somewhat infectious. If
we're going to do covenants, we should also do it as a part of a more
comprehensive new scripting system that gives us other strong benefits for
our ability to template scripts. And so on. I'm excited to see what's
possible!

Given that this is very simple to implement and has obvious deployable big
wins with few controversial drawbacks, it makes more sense to streamline
adoption of something like this for now and work on a more comprehensive
solution without urgency.

The design is also explicitly versioned so short of an eventual full
redesign it should be easy enough to add more flexible features piecemeal
as they come up and their use cases are strongly justified as I have shown
here for certified post dated utxo creation.

Lastly I think that while these are classifiable as covenants in
implementation, they are closer in use to multisig pre-signed scripts,
without the requirement of interactive setup. We should think of these as
'certified checks' instead, which can also describe a pre-signed design
satisfactorily. With true covenants we don't want require the satisfying
conditions to be 'computationally enumerable' (e.g. we can't in
computational limits enumerate all public keys if the covenant expresses a
spend must be to a public key). And if the covenant is computationally
enumerable, then we should use this construct and put the spending paths
into a Huffman encoded taproot tree.

On Tue, May 21, 2019, 12:41 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> If we're going to do covenants (and I think we should), then I think we
> need to have a flexible solution that provides more features than just
> this, or we risk adding it only to go through all the effort again when
> people ask for a better solution.
>
> Matt
>
> On 5/20/19 8:58 PM, Jeremy via bitcoin-dev 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 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.
> >
> > The BIP draft is here:
> >
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.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
> >
>

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

<div dir=3D"auto"><div>I agree a little bit, but I think that logic is some=
what infectious. If we&#39;re going to do covenants, we should also do it a=
s a part of a more comprehensive new scripting system that gives us other s=
trong benefits for our ability to template scripts. And so on. I&#39;m exci=
ted to see what&#39;s possible!</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Given that this is very simple to implement and has obvious deplo=
yable big wins with few controversial drawbacks, it makes more sense to str=
eamline adoption of something like this for now and work on a more comprehe=
nsive solution without urgency.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The design is also explicitly versioned so short of an eventual f=
ull redesign it should be easy enough to add more flexible features pieceme=
al as they come up and their use cases are strongly justified as I have sho=
wn here for certified post dated utxo creation.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Lastly I think that while these are classifiable as=
 covenants in implementation, they are closer in use to multisig pre-signed=
 scripts, without the requirement of interactive setup. We should think of =
these as &#39;certified checks&#39; instead, which can also describe a pre-=
signed design satisfactorily. With true covenants we don&#39;t want require=
 the satisfying conditions to be &#39;computationally enumerable&#39; (e.g.=
 we can&#39;t in computational limits enumerate all public keys if the cove=
nant expresses a spend must be to a public key). And if the covenant is com=
putationally enumerable, then we should use this construct and put the spen=
ding paths into a Huffman encoded taproot tree.<br><br><div class=3D"gmail_=
quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 21, 2=
019, 12:41 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorallo.com" =
rel=3D"noreferrer noreferrer" target=3D"_blank">lf-lists@mattcorallo.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we&#39;re going to =
do covenants (and I think we should), then I think we<br>
need to have a flexible solution that provides more features than just<br>
this, or we risk adding it only to go through all the effort again when<br>
people ask for a better solution.<br>
<br>
Matt<br>
<br>
On 5/20/19 8:58 PM, Jeremy via bitcoin-dev wrote:<br>
&gt; Hello bitcoin-devs,<br>
&gt; <br>
&gt; Below is a link to a BIP Draft for a new opcode,<br>
&gt; OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustles=
s<br>
&gt; congestion control techniques via a rudimentary, limited form of<br>
&gt; covenant which does not bear the same technical and social risks of<br=
>
&gt; prior covenant designs.<br>
&gt; <br>
&gt; Congestion control allows Bitcoin users to confirm payments to many<br=
>
&gt; users in a single transaction without creating the UTXO on-chain until=
 a<br>
&gt; later time. This therefore improves the throughput of confirmed<br>
&gt; payments, at the expense of latency on spendability and increased<br>
&gt; average block space utilization. The BIP covers this use case in detai=
l,<br>
&gt; and a few other use cases lightly.<br>
&gt; <br>
&gt; The BIP draft is here:<br>
&gt; <a href=3D"https://github.com/JeremyRubin/bips/blob/op-checkoutputshas=
hverify/bip-coshv.mediawiki" rel=3D"noreferrer noreferrer noreferrer norefe=
rrer" target=3D"_blank">https://github.com/JeremyRubin/bips/blob/op-checkou=
tputshashverify/bip-coshv.mediawiki</a><br>
&gt; <br>
&gt; The BIP proposes to deploy the change simultaneously with Taproot as a=
n<br>
&gt; OPSUCCESS, but it could be deployed separately if needed.<br>
&gt; <br>
&gt; An initial reference implementation of the consensus changes and=C2=A0=
 tests<br>
&gt; which demonstrate how to use it for basic congestion control is<br>
&gt; available at<br>
&gt; <a href=3D"https://github.com/JeremyRubin/bitcoin/tree/congestion-cont=
rol" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">=
https://github.com/JeremyRubin/bitcoin/tree/congestion-control</a>.=C2=A0 T=
he<br>
&gt; changes are about 74 lines of code on top of sipa&#39;s Taproot refere=
nce<br>
&gt; implementation.<br>
&gt; <br>
&gt; Best regards,<br>
&gt; <br>
&gt; Jeremy Rubin<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefe=
rrer noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
</blockquote></div></div></div>

--000000000000a1e2f20589702583--