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. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor <rocon...@blockstream.com> wrote: > There is one line written at > https://github.com/ElementsProject/elements/pull/949/files#r660130155. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
