From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E0CC8C000E for ; Tue, 6 Jul 2021 18:36:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id CD7E140111 for ; Tue, 6 Jul 2021 18:36:46 +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 ViJzHY9QHYsW for ; Tue, 6 Jul 2021 18:36:45 +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 7633F400A8 for ; Tue, 6 Jul 2021 18:36:45 +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 166Iahim028393 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 6 Jul 2021 14:36:43 -0400 Received: by mail-io1-f51.google.com with SMTP id b1so4948299ioz.8 for ; Tue, 06 Jul 2021 11:36:43 -0700 (PDT) X-Gm-Message-State: AOAM530hP9N1CMX2sqYhQWFBgEbXK+DuOxIQSrcorLKNegLilr0StfBg r8ytUQggDAezES8xoHs5zosQ2+ARn16mWsmPJF8= X-Google-Smtp-Source: ABdhPJwEaYCmNTnzubgbj563Nb4Y8ebI/9z11xIrBOxzXMG96Kxn9Pzwne3BbcWZuaH9NX7AgOpl+jUlBSj34ver/qg= X-Received: by 2002:a05:6638:168a:: with SMTP id f10mr12884097jat.73.1625596603115; Tue, 06 Jul 2021 11:36:43 -0700 (PDT) MIME-Version: 1.0 References: <20210704011341.ddbiruuomqovrjn6@ganymede> <20210704203230.37hlpdyzr4aijiet@ganymede> <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com> In-Reply-To: From: Jeremy Date: Tue, 6 Jul 2021 11:36:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000013ad0505c678b443" Subject: Re: [bitcoin-dev] Unlimited covenants, was Re: 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: Tue, 06 Jul 2021 18:36:47 -0000 --00000000000013ad0505c678b443 Content-Type: text/plain; charset="UTF-8" heh -- I pointed out these evil multisig covenants in 2015 :) https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78 I'm relatively unconcerned by it except to the extent that mining centralizes to the point of censoring other traffic. Overall, I think this is a great conversation to be having. However, I want to push back on David's claim that "Respecting the concerns of others doesn't require lobotomizing useful tools.". CHECKSIGFROMSTACK is a primitive and the opcode is not being nerfed in any way shape or form. The argument here is that doing CSFS and not CAT is nerfing CSFS... but CSFS is an independently useful and cool opcode that has many of it's own merits. Further, as described in my [blog post]( https://rubin.io/blog/2021/07/02/covenants/), CSFS has very high "design specificity"... that is there's not *that* many design choices that could possibly go into it. It's checking a signature. From the stack. That's all folks! There are no design compromises in it. No lobotomy. OP_CAT is more or less completely unrelated to CSFS. As Andrew has [demonstrated]( https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html), *just* OP_CAT alone (no CSFS) gives you covenants (albeit in a hacky way) with Schnorr. I think roconnor agrees that CAT(+CSFS?) are not really a "fantastic" way to do covenants, that there are more direct approaches that will be better or neccessary such as TWEAK or UPDATETAPLEAF. Let's work on those! But let's also not hold up progress on other useful things while those are brewing. Non-Redundancy should be a non-goal for script -- although we strive to be minimal, redundancy is inevitable. For example, OP_SWAP has identical semantics to <1> ROLL, but SWAP is a common enough use that it is pragmatic to assign it an opcode and OP_ROLL does something distinctly enhanced. Similarly, even if we add CAT we will surely come up with saner ways to implement covenant logic than Andrew's Schnorr tricks. CTV in particular is designed to be a part of that story -- enough functionality w/o OP_CAT to work *today* and serve a purpose long into the future, but with OP_CAT (or shastream preferably) enhances it's functionality in a useful way and with introspection opcodes (perhaps like those being developed by elements) further gains functionality. Perhaps the functionality available today will be redundant with a future way of doing things, but we can only see so far into the future. However, we can see that there are good things to build with it today. It's the inverse of a lobotomy. Independent components that can come together for a newer greater purpose rather than parts being torn apart irreparably. In the future when we have specific use cases in mind that *aren't* served well (either efficiently or at all) by the existing primitives, it's completely acceptable to add something new even if it makes an existing feature redundant. APO, for example, will be redundant (afaict) will Glen Willen's [Bitmask SigHash Flags]( https://bc-2.jp/archive/season2/materials/0203_NewElementsFeaturesEn.pdf) should we ever get those. -- @JeremyRubin --00000000000013ad0505c678b443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
heh -- I= pointed out these evil multisig covenants in 2015 :) https://medium.com/@jeremyrubin/regulati= ng-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78 I'm re= latively unconcerned by it except to the extent that mining centralizes to = the point of censoring other traffic.

Overall, I think this is a = great conversation to be having.

=
However, I want to push back on Davi= d's claim that=C2=A0 "Respecting the concerns of others doesn'= t require lobotomizing useful tools.".

CHECKSIGFROMSTACK is a pr= imitive and the opcode is not being nerfed in any way shape or form. The ar= gument here is that doing CSFS and not CAT is nerfing CSFS... but CSFS is a= n independently useful and cool opcode that has many of it's own merits= .

Further, as described in my [blog post](https://rubin.io/blog/2021/07/02/covenant= s/), CSFS has very high "design specificity"... that is there= 's not *that* many design choices that could possibly go into it. It= 9;s checking a signature. From the stack. That's all folks! There are n= o design compromises in it. No lobotomy.

OP_CAT is more or less = completely unrelated to CSFS. As Andrew has [demonstrated](https://ww= w.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html), *just* OP_= CAT alone (no CSFS) gives you covenants (albeit in a hacky way) with Schnor= r.

I think roconnor agrees that CAT(+CSFS?) are not really a &quo= t;fantastic" way to do covenants, that there are more direct approache= s that will be better or neccessary such as TWEAK or UPDATETAPLEAF. Let'= ;s work on those! But let's also not hold up progress on other useful t= hings while those are brewing.
<= br>
Non-Redundancy should be a non-go= al for script -- although we strive to be minimal, redundancy is inevitable= . For example, OP_SWAP has identical semantics to <1> ROLL, but SWAP = is a common enough use that it is pragmatic to assign it an opcode and OP_R= OLL does something distinctly enhanced. Similarly, even if we add CAT we wi= ll surely come up with saner ways to implement covenant logic than Andrew&#= 39;s Schnorr tricks.

CTV in particular is designed to be a part o= f that story -- enough functionality w/o OP_CAT to work *today* and serve a= purpose long into the future, but with OP_CAT (or shastream preferably) en= hances it's functionality in a useful way and with introspection opcode= s (perhaps like those being developed by elements) further gains functional= ity. Perhaps the functionality available today will be redundant with a fut= ure way of doing things, but we can only see so far into the future. Howeve= r, we can see that there are good things to build with it today.
<= /div>

It's the inverse= of a lobotomy. Independent components that can come together for a = newer greater purpose rather than part= s being torn apart irreparably.=

In the future when we have specific use cases in mind that *aren= 9;t* served well (either efficiently or at all) by the existing primitives,= it's completely acceptable to add something new even if it makes an ex= isting feature redundant. APO, for example, will be redundant (afaict) will= Glen Willen's [Bitmask SigHash Flags](https://bc-2.jp/archiv= e/season2/materials/0203_NewElementsFeaturesEn.pdf) should we ever get = those.


--00000000000013ad0505c678b443--