From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1FDD9C000E for ; Sun, 4 Jul 2021 18:40:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0E57A40163 for ; Sun, 4 Jul 2021 18:40:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwChe_b3KMf5 for ; Sun, 4 Jul 2021 18:39:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp2.osuosl.org (Postfix) with ESMTPS id 94AC7400C4 for ; Sun, 4 Jul 2021 18:39:58 +0000 (UTC) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 164IduET026899 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 4 Jul 2021 14:39:57 -0400 Received: by mail-io1-f51.google.com with SMTP id k16so18358047ios.10 for ; Sun, 04 Jul 2021 11:39:57 -0700 (PDT) X-Gm-Message-State: AOAM530v5N54gVRo3k4C5cSmud4HQSgnzMgm1Hls60Qz4tL/IvPM/dZB YwE1hItXgZAxkXvUwIcqh1lC8sAutq9UrT3G1Qo= X-Google-Smtp-Source: ABdhPJzZXwVKZ36jciUl3R31xp6/nfY/450hrFDTsVpMouh5P7htMPBsXScOD8vc70lVfAaUZr6yNhw5a4ROUVeqypM= X-Received: by 2002:a05:6602:89c:: with SMTP id f28mr8702870ioz.170.1625423996333; Sun, 04 Jul 2021 11:39:56 -0700 (PDT) MIME-Version: 1.0 References: <20210704011341.ddbiruuomqovrjn6@ganymede> In-Reply-To: <20210704011341.ddbiruuomqovrjn6@ganymede> From: Jeremy Date: Sun, 4 Jul 2021 11:39:44 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="000000000000e931db05c65083bb" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 18:40:00 -0000 --000000000000e931db05c65083bb Content-Type: text/plain; charset="UTF-8" > > Do you have concerns about sophisticated covenants, and if so, would you > mind describing them? Personally, not in particular worried about arbitrary covenants as I think that: 1 validation costs can be kept in check; 2 you're free to burn your coins it you want to. I *do* care that when we enable covenants we don't make people jump through too many hoops, but I also respect Russel's points that we can enable functionality and then later figure out how to make it more efficient or useful guided by use cases. However, I think the broader community is unconvinced by the cost benefit of arbitrary covenants. See https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6 as a recent example. Therefore as a critical part of building consensus on various techniques I've worked to emphasize that specific additions do not entail risk of accidentally introducing more than was bargained for to respect the concerns of others. > > I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2], > but it seems artificially limited without OP_CAT. (I also stand by my > answer on that survey of believing there's a deep lack of developer > interest in CSFS at the moment. But, if you'd like to tilt at that > windmill, I won't stop you.) Well if you're a fan of it, I'm a fan of it, Russel's a fan of it, and Sanket's a fan of it that sounds like a good amount of dev interest :) I know Olaoluwa is also a fan of it too and has some cool L2 protocols using it. I think it might not be *hype* because it's been around a while and has always been bundled with cat so been a non starter for the reasons above. I think as an independent non-bundle it's exciting and acceptable to a number of devs. I also believe upgrades can be developed and tracked in parallel so I'm taking on the windmill tilting personally to spearhead that -- on the shoulders of Giants who have been creating specs for this already of course. Best, Jeremy P.s. icymi https://rubin.io/blog/2021/07/02/covenants/ covers my current thinking about how to proceed w.r.t. deploying and developing covenant systems for bitcoin --000000000000e931db05c65083bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you have concerns about sophisticated covenants, and if so, would = you
mind describing them?=C2=A0

<= /div>
Personally, not in particular worried about arbitrar= y covenants as I think that: 1 validation costs can be kept in check; 2 you= 're free to burn your coins it you want to.

=
I *do* care that when we enable covenants we don= 9;t make people jump through too many hoops, but I also respect Russel'= s points that we can enable functionality and then later figure out how to = make it more efficient or useful guided by use cases.


However, I think = the broader community is unconvinced by the cost benefit of arbitrary coven= ants. See=C2=A0https://medium.com/block-di= gest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6 as= a recent example. Therefore as a critical part of building consensus on va= rious techniques I've worked to emphasize that specific additions do no= t entail risk of accidentally introducing more than was bargained for to re= spect the concerns of others.



I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2= ],
but it seems artificially limited without OP_CAT.=C2=A0 (I also stand by my=
answer on that survey of believing there's a deep lack of developer
interest in CSFS at the moment.=C2=A0 But, if you'd like to tilt at tha= t
windmill, I won't stop you.)
=
Well if you're a fan of it, I'm a fan o= f it, Russel's a fan of it, and Sanket's a fan of it that sounds li= ke a good amount of dev interest :) I know Olaoluwa is also a fan of it too= and has some cool L2 protocols using it.=C2=A0

=
I think it might not be *hype* because it's bee= n around a while and has always been bundled with cat so been a non starter= for the reasons above. I think as an independent non-bundle it's excit= ing and acceptable to a number of devs. I also believe upgrades can be deve= loped and tracked in parallel so I'm taking on the windmill tilting per= sonally to spearhead that -- on the shoulders of Giants who have been creat= ing specs for this already of course.=C2=A0

Best,

Jeremy

P.s. icymi https://rubin.io/blog/2= 021/07/02/covenants/ covers my current thinking about how to proceed w.= r.t. deploying and developing covenant systems for bitcoin
--000000000000e931db05c65083bb--