In Pieter Wuille’s recent answer [Why did BIP-342 replace CHECKMULTISIG with a new opcode], BIP-342’s
deliberate minimization of semantic changes was attributed to the
expectation that “those could always be introduced with later softforks
that redefine OP_SUCCESSes.”
I’m curious about the granularity of this reservation:
- Were specific opcode candidates (e.g., CHECKSIGFROMSTACK, CAT, TXHASH)
already on the radar when OP_SUCCESS positions were allocated, or was
the allocation purely abstract — “reserve space for unknown future use”? - Was there discussion about classes of additions (introspection opcodes,
signature variants, hash operations) that would or wouldn’t be appropriate
candidates for OP_SUCCESS redefinition vs. requiring a deeper softfork? - Are there design properties an opcode SHOULD have to be a clean
OP_SUCCESS redefinition (vs. requiring more invasive consensus changes)?
I ask because the activation-path mechanics matter for how community
discussions about future opcodes should be framed: is the conversation
“which opcode” or also “which opcode reservation slot.”
