Legacy CHECKMULTISIG has FindAndDelete hooked up to it. SegWit v0 already eliminated FindAndDelete and stored CHECKMULTISIG working tremendous. So for tapscript, the easy path was: maintain CHECKMULTISIG, say FindAndDelete does not run right here.
BIP-342 did not do this. It disabled CHECKMULTISIG fully 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 would like to grasp why.
A number of issues I am interested in:
Was a “clear CHECKMULTISIG” ever thought of, and why was it rejected?
Was the principle purpose batch verification with Schnorr, or one thing else?
Or was it a deliberate selection 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 most likely additionally shapes how future opcodes (CAT, CSFS, and so forth.) ought to look.
If anybody was a part of these discussions, I would love to listen to the precise reasoning.
Word: This isn’t about whether or not CHECKSIGADD might be retrofitted to SegWit v0 (that query has been answered — it may well’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 conserving CHECKMULTISIG with FindAndDelete eliminated?
