path: root/14/263de25bb722482c4d086763e89d03a232f084

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 67183C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 10:48:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 567EA83EC8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 10:48:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zHBQANIfiwsT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 10:48:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [IPv6:2607:f8b0:4864:20::f31])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 2CFDF830C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 10:48:57 +0000 (UTC)
Received: by mail-qv1-xf31.google.com with SMTP id kk28so4039079qvb.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 03:48:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=HlllNv2NXaZYa53q9jBzQerbzTRyTS7Zu9RD/ItbXIE=;
 b=UPh6UiVgSvff8kW+zes17J/fufFMFYTogYnk2ZevPj4XAkHXy6O7RqRY5lHZIBYUDU
 XkfTU4qOCs7MxvbY4PH++wFa+VW6nqB7PxmnHRx5W1uQcp01ikJJmGgWlQxc+lxCBIpH
 A64gZCl3Tr84m2dDcANVH8rG8heGK3eZacQ4lTi2OcDsvnQiIy1WfYvrlaAtj5+hQc6r
 PaYeS5Hj8koYbtCOJQr55fTrCUgSxxMT88EN5qdZ9Ws6U/waLjSwB3z/QgSyk5PhtZ6s
 Pk5M73Iug1nW6p8hnIgSMTuC+awBfLl7XyYqH7Z75SL5IvfVh1Ny64aJaU1jrwOw9ukV
 CvZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=HlllNv2NXaZYa53q9jBzQerbzTRyTS7Zu9RD/ItbXIE=;
 b=sPXGxzAM2jAmVpJelOCifrmaslhw2N0J0Z8XWQ5FQt9+kAHIhT/5s+RrmoVPNYYl4Y
 VAlhNWjVMY1IvYhJ3hXdo9jGjLH23/DMez/Rar8hccYN3ZAJjbHHSjYXwtY0h5Hra1PG
 Q/97h/rRE5ZJ5LieKRZIRK+sEWJaJ+b9Mm9SJLgCI7HccFAzzr+ekVoPXzOJpDEwq7F9
 b+u/eIXCeqaTJxC3mb1eCLzOLHjdoVSw7YVuA+MPMO0QJl4lOVzj1Zg/NhUjAPS41Naq
 VEXJPIf8WK7H6eklsTm3OcZDo6K9TQF4IacCIIPYB55j29CUudWiyD1Mei/ay2428NAc
 cUYw==
X-Gm-Message-State: AOAM533n9tyZpTZNyMxeBRpA1tfkBojJUSFcEMzBlq5Tn5T2g0kOimF7
 eNBKFNJX4DYWCVj/WCwhaQAe6h8OanY5ko6ggjqrRFqMCGxbrQ==
X-Google-Smtp-Source: ABdhPJzrNbbxx+NQH0CDrVbx6lFqRLX07sR+ASXJ/qBvPvSJIpILrX6IsOo0YzKTLPrtv2OhEOaTIWuSi/dxOYtixXs=
X-Received: by 2002:ad4:576d:0:b0:45a:f221:6ba7 with SMTP id
 r13-20020ad4576d000000b0045af2216ba7mr24157393qvx.14.1652352535721; Thu, 12
 May 2022 03:48:55 -0700 (PDT)
MIME-Version: 1.0
References: <161946014-482cdec305e2bd7a2c3fc4774c70239d@pmq1v.m5r2.onet>
 <M80pb4TxcE1yCMCW4IboyTtx8MSvp8m9tphXe2EYvIvcrcf2Wzsn4ManJw8EP_ri-ohqtIOPrEaw7XkUcTO3lfVSLN4WMUwpromwzLm15Kc=@protonmail.com>
 <CAMZUoKnzjcYDM-mOhT00P7YO18YmjxRkYsfO6QFtYFn0mEtLQw@mail.gmail.com>
 <fkMEju1kNN5OJPoI1d2K99sV0bhr7qeAnhVbv-99K_UL48YQyHp-rbqEfQ81crx-thaA8JuUY4-eFlYUskvFC_8h6DIhdF0Wj-v-4DNnlcI=@protonmail.com>
In-Reply-To: <fkMEju1kNN5OJPoI1d2K99sV0bhr7qeAnhVbv-99K_UL48YQyHp-rbqEfQ81crx-thaA8JuUY4-eFlYUskvFC_8h6DIhdF0Wj-v-4DNnlcI=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 12 May 2022 06:48:44 -0400
Message-ID: <CAMZUoKmhOpt2N+6YxxREMzmRca2hNnPHBMRMsT09efkEs0CJiQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ef8dcf05dece4d4d"
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
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: Thu, 12 May 2022 10:48:59 -0000

--000000000000ef8dcf05dece4d4d
Content-Type: text/plain; charset="UTF-8"

On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Russell,
>
> > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER
> RECURSIVE OR NOT.
> >
> >
> > I think the state of the art has advanced to the point where we can say
> "OP_CAT in tapscript enables non recursive covenants and it is unknown
> whether OP_CAT can enable recursive covenants or not".
> >
> > A. Poelstra in
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html show
> how to use CAT to use the schnorr verification opcode to get the sighash
> value + 1 onto the stack, and then through some grinding and some more CAT,
> get the actual sighash value on the stack. From there we can use SHA256 to
> get the signed transaction data onto the stack and apply introspect (using
> CAT) to build functionality similar to OP_CTV.
> >
> > The missing bits for enabling recursive covenants comes down to needing
> to transform a scriptpubkey into an taproot address, which involves some
> tweaking. Poelstra has suggested that it might be possible to hijack the
> ECDSA checksig operation from a parallel, legacy input, in order to perform
> the calculations for this tweaking. But as far as I know no one has yet
> been able to achieve this feat.
>
> Hmm, I do not suppose it would have worked in ECDSA?
> Seems like this exploits linearity in the Schnorr.
> For the ECDSA case it seems that the trick in that link leads to `s = e +
> G[x]` where `G[x]` is the x-coordinate of `G`.
> (I am not a mathist, so I probably am not making sense; in particular,
> there may be an operation to add two SECP256K1 scalars that I am not aware
> of)
>
> In that case, since Schnorr was added later, I get away by a technicality,
> since it is not *just* `OP_CAT` which enabled this style of covenant, it
> was `OP_CAT` + BIP340 v(^^);;;;;
>

Correct.


> Also holy shit math is scary.
>
> Seems this also works with `OP_SUBSTR`, simply by inverting it into
> "validate that the concatenation is correct" rather than "concatenate it
> ourselves".
>
>
>
>
> So really: are recursive covenants good or...?
> Because if recursive covenants are good, what we should really work on is
> making them cheap (in CPU load/bandwidth load terms) and private, to avoid
> centralization and censoring.
>

My view is that recursive covenants are inevitable.  It is nearly
impossible to have programmable money without it because it is so difficult
to avoid.

Given that we cannot have programmable money without recursive covenants
and given all the considerations already discussed regarding them, i.e. no
worse than being compelled to co-sign transactions, and that user generated
addresses won't be encumbered by a covenant unless they specifically
generate it to be, I do think it makes sense to embrace them.


> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnS=
CPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">Good morning Russell,<br>
<br>
&gt; On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER R=
ECURSIVE OR NOT.<br>
&gt;<br>
&gt;<br>
&gt; I think the state of the art has advanced to the point where we can sa=
y &quot;OP_CAT in tapscript enables non recursive covenants and it is unkno=
wn whether OP_CAT can enable recursive covenants or not&quot;.<br>
&gt;<br>
&gt; A. Poelstra in <a href=3D"https://www.wpsoftware.net/andrew/blog/cat-a=
nd-schnorr-tricks-i.html" rel=3D"noreferrer" target=3D"_blank">https://www.=
wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html</a> show how to us=
e CAT to use the schnorr verification opcode to get the sighash value + 1 o=
nto the stack, and then through some grinding and some more CAT, get the ac=
tual sighash value on the stack. From there we can use SHA256 to get the si=
gned transaction data onto the stack and apply introspect (using CAT) to bu=
ild functionality similar to OP_CTV.<br>
&gt;<br>
&gt; The missing bits for enabling recursive covenants comes down to needin=
g to transform a scriptpubkey into an taproot address, which involves some =
tweaking. Poelstra has suggested that it might be possible to hijack the EC=
DSA checksig operation from a parallel, legacy input, in order to perform t=
he calculations for this tweaking. But as far as I know no one has yet been=
 able to achieve this feat.<br>
<br>
Hmm, I do not suppose it would have worked in ECDSA?<br>
Seems like this exploits linearity in the Schnorr.<br>
For the ECDSA case it seems that the trick in that link leads to `s =3D e +=
 G[x]` where `G[x]` is the x-coordinate of `G`.<br>
(I am not a mathist, so I probably am not making sense; in particular, ther=
e may be an operation to add two SECP256K1 scalars that I am not aware of)<=
br>
<br>
In that case, since Schnorr was added later, I get away by a technicality, =
since it is not *just* `OP_CAT` which enabled this style of covenant, it wa=
s `OP_CAT` + BIP340 v(^^);;;;;<br></blockquote><div><br></div><div>Correct.=
</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">
Also holy shit math is scary.<br>
<br>
Seems this also works with `OP_SUBSTR`, simply by inverting it into &quot;v=
alidate that the concatenation is correct&quot; rather than &quot;concatena=
te it ourselves&quot;.<br>
<br>
<br>
<br>
<br>
So really: are recursive covenants good or...?<br>
Because if recursive covenants are good, what we should really work on is m=
aking them cheap (in CPU load/bandwidth load terms) and private, to avoid c=
entralization and censoring.<br></blockquote><div><br></div><div>My view is=
 that recursive covenants are inevitable.=C2=A0 It is nearly impossible to =
have programmable money without it because it is so difficult to avoid.</di=
v><div><br></div><div>Given that we cannot have programmable money without =
recursive covenants and given all the considerations already discussed rega=
rding them, i.e. no worse than being compelled to co-sign transactions, and=
 that user generated addresses won&#39;t be encumbered by a covenant unless=
 they specifically generate it to be, I do think it makes sense to embrace =
them.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--000000000000ef8dcf05dece4d4d--