path: root/43/fb85654f4c9e21aeef27f2013856977866b9e9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3F280C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 17:29:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 20D0082503
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 17:29:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 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=gmail.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 10j6aJTiCx1x
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 17:28:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com
 [IPv6:2607:f8b0:4864:20::1030])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 48BD881288
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 17:28:59 +0000 (UTC)
Received: by mail-pj1-x1030.google.com with SMTP id
 gj17-20020a17090b109100b001d8b390f77bso8476291pjb.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 10:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=O3tYYoLk/Wam3I/JDt6RNafJUb2M2QrWubN0sG9jnuU=;
 b=g1ipqGKnLeackC8pAWCQZBpYz1ZX0btg6gtxQZbXL9DcyElVRHoP/oGLU/tBAPEtDz
 y5+5A8OcVqM3Ootg1Z+uvb5C/5sJBHJBDCdDLtEu8uuj6DOmyhzXsYlmM8wHdEV5pvow
 D6tqBSws8XJoHJKYRliSKonEUAwQMHI3EOHkpllecg/YS7VaWRwMQIbn9ClR4RY1Kr5h
 4w7NgYbm3iZGBpEmcyiZoAbUziyOjy0VJRSZ+ctizM/q2X5YlEwFdRkY2Oye+++iNR0q
 I1SwxPquPCJ76GtMRtriB525KWeEwtH4rAfYwloM00EBv1WayPyQAB7Qq0lmrzNTJCYf
 /NTA==
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:cc;
 bh=O3tYYoLk/Wam3I/JDt6RNafJUb2M2QrWubN0sG9jnuU=;
 b=KmPzDGrtsczBz7OWwcs5qYuainTmYgLe5P7/benJtxvji/vkEcfHhocS8ZBWjCeqKA
 /FEN7in+xXdmzLQoYgX3fC0nKwvS4Wik2GBMTkYuRwHsvJ1Yv46sGJ5E3axuQVFOETJo
 DEpvUJb1LdpaUjrzegjWtCkGKB99+FWLxoCBjLlp8PJ4lpyKXII4WRxQGrupKXY86Icn
 75/GQTFqivPuGvwlYEfBP/soss4gB83EIR4yn9xVvlnUdvcEno0/bY1KYJbKsFq2kgEE
 rJVKJd2xMupb24/TDxP7GmyVuf5G+i5Ovqsqqk+smd3wB3z15beyqQ01QYzcJvbVcm/Z
 dslQ==
X-Gm-Message-State: AOAM532xuZJE6bzJlbHdgmhRnxLKkaI/aNzwMHAbhclaVQPVHhaG+UR+
 ra6EM74M/ZQuEeP77WiS9koVWlVRK0UlqmldI6gAgMfBGo0=
X-Google-Smtp-Source: ABdhPJzbJxZr7E0hRHvmVvZHHvJB3ojwQOR5eGIg90tBOnMnJQDaqM/AKGS2a8B/DS8MScwPUZa8k6P6WyMFMvsnSSQ=
X-Received: by 2002:a17:902:c952:b0:15e:9e3d:8e16 with SMTP id
 i18-20020a170902c95200b0015e9e3d8e16mr934724pla.51.1652376537508; Thu, 12 May
 2022 10:28:57 -0700 (PDT)
MIME-Version: 1.0
References: <kbrvpw3Y5y3ko3Wf2VtcywN462JjMW6YjqecduPOXwrek2sR9FkWfSv6G2Fph22UTAAbgII88MtOn1AFo223jjryNAz8YNbbQlFRVQo_HMY=@protonmail.com>
 <CABm2gDqxOtrMrTu2Ovx32USJT2T+6DRpexct1-k3zwEEnsDPMA@mail.gmail.com>
 <HfqjtQb_3TfhHaAZzYOcUoMic1iG40qUjqlKpzOZY6PSBW1bXVFtFW4zCHFRUdOoIhrard9ZPslzbrIYO0cM-Oi37mLzeEv6MZiQ7JtulE4=@protonmail.com>
 <CAGpPWDZVqas6v9nQtGtgk2mMOw9KQ+=dytBc+fBE6SNL=F3bqQ@mail.gmail.com>
 <CALeFGL18ULkGW4UA_5Fod4PVoe_LeF5e97eZdJja-ctf2paLWQ@mail.gmail.com>
 <CAGpPWDYUTCsSgirR7iNmbUw+cjEqHSymtzH4EtH=BQnZRjvgmQ@mail.gmail.com>
 <CABm2gDqVcAAz-Nqwt+SPBZrFyTUN3kizSTYkbuWSkoG0xJtoPQ@mail.gmail.com>
 <YexjEuO_SQawFcFWRGWAoZ0aVZqw6_pem6IGvCrTUGW1Q6WoKFbQXMzf9ICkpxn1ffLGFnvCWv8205dv97pZo9CzfiUA7Q53-X2Sd7uCQEM=@protonmail.com>
In-Reply-To: <YexjEuO_SQawFcFWRGWAoZ0aVZqw6_pem6IGvCrTUGW1Q6WoKFbQXMzf9ICkpxn1ffLGFnvCWv8205dv97pZo9CzfiUA7Q53-X2Sd7uCQEM=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 12 May 2022 12:28:39 -0500
Message-ID: <CAGpPWDaDofscrK=k-Ej4Ze1u-VaoiJ1-Liy6DuuO3Wuss0aoyQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000008dae5005ded3e40d"
X-Mailman-Approved-At: Thu, 12 May 2022 17:54:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP Meeting #8 Notes
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 17:29:00 -0000

--0000000000008dae5005ded3e40d
Content-Type: text/plain; charset="UTF-8"

@Jorge & Zmn
>  A recursive covenant guarantees that the same thing will happen in the
future.

Just a clarification: a recursive covenant does not necessarily guarantee
any particular thing will happen in the future. Both recursives and a
non-recursive covenant opcodes *can* be used to guarantee something will
happen. Neither *necessarily* guarantee anything (because of
the possibility of alternative spend paths). A covenant isn't just a
promise, its a restriction.

A "recursive covenant" opcode is one that allows loops in the progression
through covenant addresses. Here's an example of a set of transitions from
one address with a covenant in the spend path to another (or "exit" which
does not have a covenant restriction):

A -> B
A -> C
B -> C
C -> A
C -> exit

The possible combinations of changes are:

A -> B -> C -> exit
A -> C -> A -> ...
A -> B -> C -> A -> ...

This would be a recursive covenant with an exit. Remove the exit
transition, and you have a walled garden. Even with this walled garden, you
can avoid going through address B (since you can skip directly to C).

A covenant opcode that can allow for infinite recursion (often talked about
as a "recursive covenant") can be used to return to a previous state, which
allows for permanent walled gardens.

So I would instead characterize a bitcoin covenant as:

A covenant in an input script places a requirement/restriction on the
output script(s) that input sends to. Pretty much any covenant allows for a
chain or graph of covenant-laden addresses to be prescribed, while a
"recursive covenant" opcode allows previous nodes in that graph to be
returned to such that the states can be looped through forever (which may
or may not have some way to exit).

One potentially confusing thing about the way covenants are usually talked
about is that in technical discussions about the risks of covenants, what
is being talked about is not what a particular covenant opcode always does,
but rather what the boundaries are on what can be done with that opcode.
Pretty much any recursive covenant you could design would be able to be
used to create normal simple non-walled-garden situations. The question is,
since they do allow someone to create walled gardens, is that ok.

I suppose maybe an interesting possibility would be to have a covenant
limit placed into a covenant opcode. Eg, let's say that you have
OP_LIMITEDCOVENANT (OP_LC) and OP_LC specifies that the maximum covenant
chain is 100. The 100th consecutive output with an OP_LC use could simply
ignore it and be spent normally to anywhere (given that the rest of the
script allows it). This could effectively prevent the ability to create
walled gardens, without eliminating most interesting use cases. Among
people who care about covenants on this mailing list, the consensus seems
to be that infinitely recursive covenants are not something to be afraid
of. However, if maybe something like this could make more powerful
covenants acceptable to a larger group of people, it could be worth doing.

On Thu, May 12, 2022 at 7:20 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Jorge,
>
> > I fail to understand why non recursive covenants are called covenants at
> all. Probably I'm missing something, but I guess that's another topic.
>
> A covenant simply promises that something will happen in the future.
>
> A recursive covenant guarantees that the same thing will happen in the
> future.
>
> Thus, non-recursive covenants can be useful.
>
> Consider `OP_EVICT`, for example, which is designed for a very specific
> use-case, and avoids recursion.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><div>@Jorge &amp; Zmn<br></div>&gt;=C2=A0

A recursive covenant guarantees that the same thing will happen in the futu=
re.<div><br></div><div>Just a clarification: a recursive covenant does not =
necessarily guarantee any particular thing will happen in the future. Both =
recursives and a non-recursive covenant opcodes *can* be used to guarantee =
something will happen. Neither *necessarily* guarantee anything (because of=
 the=C2=A0possibility of alternative spend paths). A covenant isn&#39;t jus=
t a promise, its a restriction.=C2=A0=C2=A0</div><div><br></div><div>A &quo=
t;recursive covenant&quot; opcode is one that allows loops in the progressi=
on through covenant addresses. Here&#39;s an example of a set of transition=
s from one address with a covenant in the spend path to another (or &quot;e=
xit&quot; which does not have a covenant restriction):</div><div><br></div>=
<div>A -&gt; B</div><div>A -&gt; C</div><div>B -&gt; C</div><div>C -&gt; A<=
/div><div>C -&gt; exit</div><div><br></div><div>The possible combinations o=
f changes are:</div><div><br></div><div>A -&gt; B -&gt; C -&gt; exit</div><=
div>A -&gt; C -&gt; A -&gt; ...</div><div>A -&gt; B -&gt; C -&gt; A -&gt; .=
..</div><div><br></div><div>This would be a recursive covenant with an exit=
. Remove the exit transition, and you have a walled garden. Even with this =
walled garden, you can avoid going through address B (since you can skip di=
rectly to C).=C2=A0</div><div><br></div><div>A covenant opcode that can all=
ow for infinite recursion (often talked about as a &quot;recursive covenant=
&quot;) can be used to return to a previous state, which allows for permane=
nt walled gardens.=C2=A0=C2=A0</div><div><br></div><div>So I would instead =
characterize a bitcoin covenant as:</div><div><br></div><div>A covenant in =
an input script places a requirement/restriction on the output script(s) th=
at input sends to. Pretty much any covenant allows for a chain or graph of =
covenant-laden addresses to be prescribed, while a &quot;recursive covenant=
&quot; opcode allows previous nodes in that graph to be returned to such th=
at the states can be looped through forever (which may or may not have some=
 way to exit).=C2=A0=C2=A0</div><div><br></div><div>One potentially confusi=
ng thing about the way covenants are usually talked about is that in techni=
cal discussions about the risks of covenants, what is being talked about is=
 not what a particular covenant opcode always does, but rather what the bou=
ndaries are on what can be done with that opcode. Pretty much any recursive=
 covenant you could design would be able to be used to create normal simple=
 non-walled-garden situations. The question is, since they do allow someone=
 to create walled gardens, is that ok.=C2=A0=C2=A0</div><div><br></div><div=
>I suppose maybe an interesting possibility would be to have a covenant lim=
it placed into a covenant opcode. Eg, let&#39;s say that you have OP_LIMITE=
DCOVENANT (OP_LC) and OP_LC specifies that the maximum covenant chain is 10=
0. The 100th consecutive output with an OP_LC use could simply ignore it an=
d be spent normally to anywhere (given that the rest of the script allows i=
t). This could effectively prevent the ability to create walled gardens, wi=
thout eliminating most interesting use cases. Among people who care about c=
ovenants on this mailing list, the consensus seems to be that infinitely re=
cursive covenants are not something to be afraid of. However, if maybe some=
thing like this could make more powerful covenants acceptable to a larger g=
roup of people, it could be worth doing.=C2=A0</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 12, 2022 at=
 7:20 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@p=
rotonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">Good morning Jorge,<br>
<br>
&gt; I fail to understand why non recursive covenants are called covenants =
at all. Probably I&#39;m missing something, but I guess that&#39;s another =
topic.<br>
<br>
A covenant simply promises that something will happen in the future.<br>
<br>
A recursive covenant guarantees that the same thing will happen in the futu=
re.<br>
<br>
Thus, non-recursive covenants can be useful.<br>
<br>
Consider `OP_EVICT`, for example, which is designed for a very specific use=
-case, and avoids recursion.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--0000000000008dae5005ded3e40d--