From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3F280C002D for ; 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 ; 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 ; 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 ; Thu, 12 May 2022 17:28:59 +0000 (UTC) Received: by mail-pj1-x1030.google.com with SMTP id gj17-20020a17090b109100b001d8b390f77bso8476291pjb.1 for ; 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: In-Reply-To: From: Billy Tetrud Date: Thu, 12 May 2022 12:28:39 -0500 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000008dae5005ded3e40d" X-Mailman-Approved-At: Thu, 12 May 2022 17:54:58 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
@Jorge & Zmn
>=C2=A0 A recursive covenant guarantees that the same thing will happen in the futu= re.

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't jus= t a promise, its a restriction.=C2=A0=C2=A0

A &quo= t;recursive covenant" opcode is one that allows loops in the progressi= on through covenant addresses. Here's an example of a set of transition= s from one address with a covenant in the spend path to another (or "e= xit" which does not have a covenant restriction):

=
A -> B
A -> C
B -> C
C -> A<= /div>
C -> exit

The possible combinations o= f changes are:

A -> B -> C -> exit
<= div>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 di= rectly to C).=C2=A0

A covenant opcode that can all= ow for infinite recursion (often talked about as a "recursive covenant= ") can be used to return to a previous state, which allows for permane= nt walled gardens.=C2=A0=C2=A0

So I would instead = characterize a bitcoin covenant as:

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 "recursive covenant= " 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

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

I suppose maybe an interesting possibility would be to have a covenant lim= it placed into a covenant opcode. Eg, let'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

On Thu, May 12, 2022 at= 7:20 AM ZmnSCPxj <ZmnSCPxj@p= rotonmail.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 futu= re.

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--