ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-12 📝 Original message:Good morning Russell, > On ...
📅 Original date posted:2022-05-12
📝 Original message:Good morning Russell,
> 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.
Hmm, I do not suppose it would have worked in ECDSA?
Seems like this exploits linearity in the Schnorr.
For the ECDSA case it seems that the trick in that link leads to `s = e + G[x]` where `G[x]` is the x-coordinate of `G`.
(I am not a mathist, so I probably am not making sense; in particular, there may be an operation to add two SECP256K1 scalars that I am not aware of)
In that case, since Schnorr was added later, I get away by a technicality, since it is not *just* `OP_CAT` which enabled this style of covenant, it was `OP_CAT` + BIP340 v(^^);;;;;
Also holy shit math is scary.
Seems this also works with `OP_SUBSTR`, simply by inverting it into "validate that the concatenation is correct" rather than "concatenate it ourselves".
So really: are recursive covenants good or...?
Because if recursive covenants are good, what we should really work on is making them cheap (in CPU load/bandwidth load terms) and private, to avoid centralization and censoring.
Regards,
ZmnSCPxj
📝 Original message:Good morning Russell,
> 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.
Hmm, I do not suppose it would have worked in ECDSA?
Seems like this exploits linearity in the Schnorr.
For the ECDSA case it seems that the trick in that link leads to `s = e + G[x]` where `G[x]` is the x-coordinate of `G`.
(I am not a mathist, so I probably am not making sense; in particular, there may be an operation to add two SECP256K1 scalars that I am not aware of)
In that case, since Schnorr was added later, I get away by a technicality, since it is not *just* `OP_CAT` which enabled this style of covenant, it was `OP_CAT` + BIP340 v(^^);;;;;
Also holy shit math is scary.
Seems this also works with `OP_SUBSTR`, simply by inverting it into "validate that the concatenation is correct" rather than "concatenate it ourselves".
So really: are recursive covenants good or...?
Because if recursive covenants are good, what we should really work on is making them cheap (in CPU load/bandwidth load terms) and private, to avoid centralization and censoring.
Regards,
ZmnSCPxj