@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 <zmnsc...@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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
