Legacy CHECKMULTISIG has FindAndDelete hooked up to it. SegWit v0 already eliminated FindAndDelete and saved CHECKMULTISIG working fantastic. So for tapscript, the straightforward path was: hold CHECKMULTISIG, say FindAndDelete does not run right here.
BIP-342 did not do 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.
A number of issues I am interested in:
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 selection to maneuver away from opcodes that pack entire 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 most likely 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.
Word: 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 could be a hardfork). My query is the wrong way: when designing tapscript, why introduce CHECKSIGADD in any respect, as an alternative of preserving CHECKMULTISIG with FindAndDelete eliminated?
