diff options
| author | Jeremy <jlrubin@mit.edu> | 2021-07-04 11:39:44 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-07-04 18:40:00 +0000 |
| commit | a90825004a8a211384ef864afd3ada2931e299e5 (patch) | |
| tree | 559432964b11783daef8444437c45fa9d9ad8425 /9b | |
| parent | 1cdaeee3fd8007aa9a6f50484592fb31987a9b0c (diff) | |
| download | pi-bitcoindev-a90825004a8a211384ef864afd3ada2931e299e5.tar.gz pi-bitcoindev-a90825004a8a211384ef864afd3ada2931e299e5.zip | |
Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
Diffstat (limited to '9b')
| -rw-r--r-- | 9b/3a86c7317d37134baf7b75ba7fa2ce669ad75f | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/9b/3a86c7317d37134baf7b75ba7fa2ce669ad75f b/9b/3a86c7317d37134baf7b75ba7fa2ce669ad75f new file mode 100644 index 000000000..cda29c2a3 --- /dev/null +++ b/9b/3a86c7317d37134baf7b75ba7fa2ce669ad75f @@ -0,0 +1,178 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 1FDD9C000E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; Sun, 4 Jul 2021 14:39:57 -0400 +Received: by mail-io1-f51.google.com with SMTP id k16so18358047ios.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com> + <20210704011341.ddbiruuomqovrjn6@ganymede> +In-Reply-To: <20210704011341.ddbiruuomqovrjn6@ganymede> +From: Jeremy <jlrubin@mit.edu> +Date: Sun, 4 Jul 2021 11:39:44 -0700 +X-Gmail-Original-Message-ID: <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com> +Message-ID: <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com> +To: "David A. Harding" <dave@dtrt.org> +Content-Type: multipart/alternative; boundary="000000000000e931db05c65083bb" +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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 + +<div dir=3D"auto"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai= +l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= +:1ex">Do you have concerns about sophisticated covenants, and if so, would = +you<br> +mind describing them?=C2=A0</blockquote></div></div><div dir=3D"auto"><br><= +/div><div dir=3D"auto">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.</div><div dir=3D"auto"><br>= +</div><div dir=3D"auto">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.</div><div dir=3D"auto= +"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">However, I think = +the broader community is unconvinced by the cost benefit of arbitrary coven= +ants. See=C2=A0<a href=3D"https://medium.com/block-digest-mempool/my-worrie= +s-about-too-generalized-covenants-5eff33affbb6">https://medium.com/block-di= +gest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6</a> 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.</div><div dir=3D"auto"><br></div><div dir=3D"= +auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D= +"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> +<br> +I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2= +],<br> +but it seems artificially limited without OP_CAT.=C2=A0 (I also stand by my= +<br> +answer on that survey of believing there's a deep lack of developer<br> +interest in CSFS at the moment.=C2=A0 But, if you'd like to tilt at tha= +t<br> +windmill, I won't stop you.)</blockquote></div></div><div dir=3D"auto">= +<br></div><div dir=3D"auto">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</div><div dir=3D"auto"><br>= +</div><div dir=3D"auto">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</div><div dir=3D"auto"><br></di= +v><div dir=3D"auto">Best,</div><div dir=3D"auto"><br></div><div dir=3D"auto= +">Jeremy</div><div dir=3D"auto"><br></div><div dir=3D"auto">P.s. icymi <a h= +ref=3D"https://rubin.io/blog/2021/07/02/covenants/">https://rubin.io/blog/2= +021/07/02/covenants/</a> covers my current thinking about how to proceed w.= +r.t. deploying and developing covenant systems for bitcoin</div><div dir=3D= +"auto"></div></div> + +--000000000000e931db05c65083bb-- + |