Legacy CHECKMULTISIG has FindAndDelete attached to it. SegWit v0 already removed FindAndDelete and kept CHECKMULTISIG working fine. So for tapscript, the simple path was: keep CHECKMULTISIG, say FindAndDelete doesn’t run here.
BIP-342 didn’t do that. It disabled CHECKMULTISIG completely and added CHECKSIGADD, so multisig is now a sequence of opcodes plus a comparison.
That’s a much bigger change than just fixing the bug. I’d like to understand why.
A few things I’m curious about:
Was a “clean CHECKMULTISIG” ever considered, and why was it rejected?
Was the main reason batch verification with Schnorr, or something else?
Or was it a deliberate choice to move away from opcodes that pack whole patterns, toward smaller primitives that script authors combine themselves?
The last one matters to me because if it’s a real design shift, it probably also shapes how future opcodes (CAT, CSFS, etc.) should look.
If anyone was part of those discussions, I’d love to hear the actual reasoning.
Note: This is not about whether CHECKSIGADD could be retrofitted to SegWit v0 (that question has been answered — it can’t, it would be a hardfork). My question is the opposite direction: when designing tapscript, why introduce CHECKSIGADD at all, instead of keeping CHECKMULTISIG with FindAndDelete removed?
