I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound to the txdata? When might you use this?

And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to follow the semantics from bip340-342 when witness program is v1." is a bit light on detail for what the BIP would end up looking like. If you're able to open up the design process a bit more on that it would be good as I think there are some topics worth discussing at large before things proceed with Elements (assuming feature compatibility remains a goal).

The non-prehashed argument seems OK (at the cost of an extra byte...) but are there specific applications for !=32 arguments? I can't think of a particular one beyond perhaps efficiency. Can we safely use 0-520 byte arguments?

Also do you have thoughts on the other questions i posed above? E.g. splitting R/S could be helpful w/o CAT.

On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor <roconnor@blockstream.com> wrote:

There is one line written at https://github.com/ElementsProject/elements/pull/949/files#r660130155.