From: Billy Tetrud <billy.tetrud@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP Meeting #8 Notes
Date: Thu, 12 May 2022 12:28:39 -0500 [thread overview]
Message-ID: <CAGpPWDaDofscrK=k-Ej4Ze1u-VaoiJ1-Liy6DuuO3Wuss0aoyQ@mail.gmail.com> (raw)
In-Reply-To: <YexjEuO_SQawFcFWRGWAoZ0aVZqw6_pem6IGvCrTUGW1Q6WoKFbQXMzf9ICkpxn1ffLGFnvCWv8205dv97pZo9CzfiUA7Q53-X2Sd7uCQEM=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3626 bytes --]
@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
>
[-- Attachment #2: Type: text/html, Size: 4427 bytes --]
prev parent reply other threads:[~2022-05-12 17:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 2:40 alicexbt
2022-05-07 13:22 ` Jorge Timón
2022-05-07 22:40 ` ZmnSCPxj
2022-05-08 16:32 ` Billy Tetrud
2022-05-09 15:23 ` Keagan McClelland
2022-05-10 15:09 ` Billy Tetrud
2022-05-12 11:46 ` Jorge Timón
2022-05-12 12:20 ` ZmnSCPxj
2022-05-12 17:28 ` Billy Tetrud [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGpPWDaDofscrK=k-Ej4Ze1u-VaoiJ1-Liy6DuuO3Wuss0aoyQ@mail.gmail.com' \
--to=billy.tetrud@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox