📅 Original date posted:2022-05-11 📝 Original message:On Wed, May 11, 2022 at ...

Russell O'Connor [ARCHIVE] /

npub1dw8…plrw

2023-06-07 23:09:20

in reply to nevent1q…f2s4

📅 Original date posted:2022-05-11
📝 Original message:On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE
> OR NOT.
>

I think the state of the art has advanced to the point where we can say
"OP_CAT in tapscript enables non recursive covenants and it is unknown
whether OP_CAT can enable recursive covenants or not".

A. Poelstra in
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html show
how to use CAT to use the schnorr verification opcode to get the sighash
value + 1 onto the stack, and then through some grinding and some more CAT,
get the actual sighash value on the stack. From there we can use SHA256 to
get the signed transaction data onto the stack and apply introspect (using
CAT) to build functionality similar to OP_CTV.

The missing bits for enabling recursive covenants comes down to needing to
transform a scriptpubkey into an taproot address, which involves some
tweaking. Poelstra has suggested that it might be possible to hijack the
ECDSA checksig operation from a parallel, legacy input, in order to perform
the calculations for this tweaking. But as far as I know no one has yet
been able to achieve this feat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/50e8333f/attachment-0001.html>;

Author Public Key

npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw

Show more details

Published at

2023-06-07 23:09:20

Kind type

1 Short Text Note

Event JSON

{ "id": "f80cc818984c5e0f81754d08aa4b1b6409658b5f052eb06968ee5c53171146d6", "pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d", "created_at": 1686179360, "kind": 1, "tags": [ [ "e", "cbc59e6bdcc1bf5eb00c43b304431e89f4d455fde09436058aad561d6b24579e", "", "root" ], [ "e", "0b10917fbf3c54a548fdedbc32e31a8b8a51569fa2d8a70728cb8fc9896cacc9", "", "reply" ], [ "p", "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861" ] ], "content": "📅 Original date posted:2022-05-11\n📝 Original message:On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE\n\u003e OR NOT.\n\u003e\n\nI think the state of the art has advanced to the point where we can say\n\"OP_CAT in tapscript enables non recursive covenants and it is unknown\nwhether OP_CAT can enable recursive covenants or not\".\n\nA. Poelstra in\nhttps://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html show\nhow to use CAT to use the schnorr verification opcode to get the sighash\nvalue + 1 onto the stack, and then through some grinding and some more CAT,\nget the actual sighash value on the stack. From there we can use SHA256 to\nget the signed transaction data onto the stack and apply introspect (using\nCAT) to build functionality similar to OP_CTV.\n\nThe missing bits for enabling recursive covenants comes down to needing to\ntransform a scriptpubkey into an taproot address, which involves some\ntweaking. Poelstra has suggested that it might be possible to hijack the\nECDSA checksig operation from a parallel, legacy input, in order to perform\nthe calculations for this tweaking. But as far as I know no one has yet\nbeen able to achieve this feat.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/50e8333f/attachment-0001.html\u003e", "sig": "64424a49c960a7fabf2068e22c180c8146948f5aa98d0c0d35e381e4c1d6523a625929d60fe064ad81cce5abc8ffb726243e5937dd8410af647a143b2bdd8770" }