Good morning Russell, > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev > <bitcoin-dev@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
