Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 54E449F0 for ; 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 ; 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 ; Tue, 21 May 2019 21:47:25 -0400 Received: by mail-ed1-f49.google.com with SMTP id w37so1253797edw.4 for ; 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: <80353196-0f32-0e7b-d048-bd870e30029c@mattcorallo.com> In-Reply-To: <80353196-0f32-0e7b-d048-bd870e30029c@mattcorallo.com> From: Jeremy Date: Tue, 21 May 2019 18:47:11 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Matt Corallo 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
I agree a little bit, but I think that logic is some= what infectious. If we'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'm exci= ted to see what's possible!

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.

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.

=
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 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.

On Tue, May 21, 2= 019, 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 trustles= s
> 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 detai= l,
> and a few other use cases lightly.
>
> The BIP draft is here:
> https://github.com/JeremyRubin/bips/blob/op-checkou= tputshashverify/bip-coshv.mediawiki
>
> The BIP proposes to deploy the change simultaneously with Taproot as a= n
> OPSUCCESS, but it could be deployed separately if needed.
>
> An initial reference implementation of the consensus changes and=C2=A0= tests
> which demonstrate how to use it for basic congestion control is
> available at
> = https://github.com/JeremyRubin/bitcoin/tree/congestion-control.=C2=A0 T= he
> changes are about 74 lines of code on top of sipa's Taproot refere= nce
> implementation.
>
> Best regards,
>
> Jeremy Rubin
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfounda= tion.org
> = https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000a1e2f20589702583--