vjudeu at gazeta.pl [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-11 📝 Original message:> Looks like `OP_CAT` is ...
📅 Original date posted:2022-05-11
📝 Original message:> Looks like `OP_CAT` is not getting enabled until after we are reasonably sure that recursive covenants are not really unsafe.
Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT. Then, we could have OP_SPLIT <n> <pos1> <pos2> ... <posN> that would split a string N times (so there will be N+1 pieces). Or we could have just OP_SPLIT <pos> to split one string into two. Or maybe OP_2SPLIT and OP_3SPLIT, just to split into two or three pieces (as we have OP_2DUP and OP_3DUP). I think OP_SUBSTR or OP_SPLIT is better than OP_CAT, because then things always get smaller and we can be always sure that we will have one byte as the smallest unit in our Script.
On 2022-05-08 04:20:19 user ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:> Looks like `OP_CAT` is not getting enabled until after we are reasonably sure that recursive covenants are not really unsafe.
Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT. Then, we could have OP_SPLIT <n> <pos1> <pos2> ... <posN> that would split a string N times (so there will be N+1 pieces). Or we could have just OP_SPLIT <pos> to split one string into two. Or maybe OP_2SPLIT and OP_3SPLIT, just to split into two or three pieces (as we have OP_2DUP and OP_3DUP). I think OP_SUBSTR or OP_SPLIT is better than OP_CAT, because then things always get smaller and we can be always sure that we will have one byte as the smallest unit in our Script.
On 2022-05-08 04:20:19 user ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev