What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-07 23:09:19
in reply to nevent1q…7tmc

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-07 📝 Original message:Good morning shesek, > On ...

📅 Original date posted:2022-05-07
📝 Original message:Good morning shesek,

> On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > * Even ***with*** `OP_CAT`, the following will enable non-recursive covenants without enabling recursive covenants:
> >  * `OP_CTV`, ...
> > * With `OP_CAT`, the following would enable recursive covenants:
> >  * `OP_CHECKSIGFROMSTACK`, ...
>
> Why does CTV+CAT not enable recursive covenants while CSFS+CAT does?
>
> CTV+CAT lets you similarly assert against the outputs and verify that they match some dynamically constructed script.
>
> Is it because CTV does not let you have a verified copy of the input's prevout scriptPubKey on the stack [0], while with OP_CSFS you can because the signature hash covers it?
>
> But you don't actually need this for recursion. Instead of having the user supply the script in the witness stack and verifying it against the input to obtain the quine, the script can simply contain a copy of itself as an initial push (minus this push). You can then reconstruct the full script quine using OP_CAT, as a PUSH(<script>) followed by the literal <script>.

<OP_PUSH_length-of-script> OP_SWAP OP_DUP OP_CAT OP_CAT <rest of script...>

Ha, yes, looks like you are correct here.

`OP_CAT` makes *all* covenant opcodes recursive, because you can always quine using `OP_CAT`.

By itself it does not make recursive covenants, but with probably any opcode it would.

Looks like `OP_CAT` is not getting enabled until after we are reasonably sure that recursive covenants are not really unsafe.

Regards,
ZmnSCPxj
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l