In Pieter Wuille’s recent answer (Why BIP-342 replaced CHECKMULTISIG with a new opcode), BIP-342’s intentional minimal semantic changes stem from the expectation that it “can always be introduced via a recent softfork that redefines OP_SUCCESS.”
I would like to know the details of this reservation.
- Were certain opcode candidates (e.g. CHECKSIGFROMSTACK, CAT, TXHASH) already on the radar when the OP_SUCCESS position was assigned? Or was the assignment purely abstract? Was it “reserve space for unknown future use”?
- Has there been any discussion about additional classes (self-checking opcodes, signature variants, hash operations) that may or may not be candidates for an OP_SUCCESS override and a deeper softfork?
- Are there any design properties that require the opcode to be a clean OP_SUCCESS override (versus a more intrusive consensus change requirement)?
I ask because the activation path mechanism is important to how we structure community discussions about opcodes in the future. The dialogue is “opcode” or “opcode reserved slot”.