Why did BIP-342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it?

External question — Bitcoin Stack Exchange Author: Aaron Zhang Original post: https://bitcoin.stackexchange.com/questions/130665 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. 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?

External answer — Bitcoin Stack Exchange Author: Pieter Wuille Original post: https://bitcoin.stackexchange.com/a/130666 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. The entire reason for removing OP_CHECKMULTISIG ( VERIFY ), and replacing it with OP_CHECKSIGADD , was to enable batch validation - something that could not be done with a later separate softfork (because it wouldn't be able to force people to migrate to new batch-verifiability-compatible opcodes). Semantics changes were kept to a minimum, as those could always be introduced with later softforks that redefine OP_SUCCESS es.