path: root/2a/8dee875bb923691b84a6303fdfc6768b8a077a

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E0CC8C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Tue, 6 Jul 2021 14:36:43 -0400
Received: by mail-io1-f51.google.com with SMTP id b1so4948299ioz.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
 <20210704011341.ddbiruuomqovrjn6@ganymede>
 <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
 <20210704203230.37hlpdyzr4aijiet@ganymede>
 <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com>
 <CAMZUoKnuRXNG1pyupHrL+Wo80TXTbADVrexoB=+BKC633v-qMw@mail.gmail.com>
 <CAGpPWDZ6FhAn+dBf-_yf7YVzRB7NWV7zaKqKYewgZecBxWUx5A@mail.gmail.com>
 <CAMZUoKkAUodCT+2aQG71xwHYD8KXeTAdQq4NmXZ4GBe0pcD=9A@mail.gmail.com>
In-Reply-To: <CAMZUoKkAUodCT+2aQG71xwHYD8KXeTAdQq4NmXZ4GBe0pcD=9A@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 6 Jul 2021 11:36:31 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhm+TejnVV-pxEmE0_msUzXU1njMDbjrYb4vd0Kti-Xkg@mail.gmail.com>
Message-ID: <CAD5xwhhm+TejnVV-pxEmE0_msUzXU1njMDbjrYb4vd0Kti-Xkg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">heh -- I=
 pointed out these evil multisig covenants in 2015 :) <a href=3D"https://me=
dium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-atta=
ck-c8fd51185b78" target=3D"_blank">https://medium.com/@jeremyrubin/regulati=
ng-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78</a> I&#39;m re=
latively unconcerned by it except to the extent that mining centralizes to =
the point of censoring other traffic.<br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000">Overall, I think this is a =
great conversation to be having.</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">However, I want to push back on Davi=
d&#39;s claim that=C2=A0 &quot;Respecting the concerns of others doesn&#39;=
t require lobotomizing useful tools.&quot;.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">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&#39;s own merits=
. <br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">Further, as described in my [blog post](<a href=3D"https://rub=
in.io/blog/2021/07/02/covenants/">https://rubin.io/blog/2021/07/02/covenant=
s/</a>), CSFS has very high &quot;design specificity&quot;... that is there=
&#39;s not *that* many design choices that could possibly go into it. It&#3=
9;s checking a signature. From the stack. That&#39;s all folks! There are n=
o design compromises in it. No lobotomy. <br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000">OP_CAT is more or less =
completely unrelated to CSFS. As Andrew has [demonstrated](<a href=3D"https=
://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html">https://ww=
w.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html</a>), *just* OP_=
CAT alone (no CSFS) gives you covenants (albeit in a hacky way) with Schnor=
r.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">I think roconnor agrees that CAT(+CSFS?) are not really a &quo=
t;fantastic&quot; way to do covenants, that there are more direct approache=
s that will be better or neccessary such as TWEAK or UPDATETAPLEAF. Let&#39=
;s work on those! But let&#39;s also not hold up progress on other useful t=
hings while those are brewing.<br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">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 &lt;1&gt; 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.<br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">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&#39;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.<br></div><=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><span class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">I</span>t&#39;s the <span class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">inverse=
 of a lobotomy</span>. Independent components that can come together for a =
newer greater purpose rather than <span class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">part=
s</span> being torn apart<span class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"> irreparably.=
</span><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">In the future when we have specific use cases in mind that *aren&#3=
9;t* served well (either efficiently or at all) by the existing primitives,=
 it&#39;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&#39;s [Bitmask SigHash Flags](<a href=3D"https://bc-2.jp/archi=
ve/season2/materials/0203_NewElementsFeaturesEn.pdf">https://bc-2.jp/archiv=
e/season2/materials/0203_NewElementsFeaturesEn.pdf</a>) should we ever get =
those.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div><div dir=3D=
"ltr" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"=
https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></di=
v><br></div><br></div>

--00000000000013ad0505c678b443--