Legacy CHECKMULTISIG has FindAndDelete hooked up to it. SegWit v0 already eliminated FindAndDelete and saved CHECKMULTISIG working fantastic. So for tapscript, the easy path was: preserve CHECKMULTISIG, say FindAndDelete does not run right here.
BIP-342 did not try this. It disabled CHECKMULTISIG utterly and added CHECKSIGADD, so multisig is now a sequence of opcodes plus a comparability.
That is a a lot greater change than simply fixing the bug. I might like to know why.
Just a few issues I am interested by:
Was a “clear CHECKMULTISIG” ever thought of, and why was it rejected?
Was the primary purpose batch verification with Schnorr, or one thing else?
Or was it a deliberate alternative to maneuver away from opcodes that pack complete patterns, towards smaller primitives that script authors mix themselves?
The final one issues to me as a result of if it is an actual design shift, it in all probability additionally shapes how future opcodes (CAT, CSFS, and so forth.) ought to look.
If anybody was a part of these discussions, I might love to listen to the precise reasoning.
Observe: This isn’t about whether or not CHECKSIGADD could possibly be retrofitted to SegWit v0 (that query has been answered — it could possibly’t, it might be a hardfork). My query is the other way: when designing tapscript, why introduce CHECKSIGADD in any respect, as an alternative of preserving CHECKMULTISIG with FindAndDelete eliminated?
