This approach stems from concerns highlighted by Murch regarding the conventional method of adding new opcodes, such as CHECKSIGFROMSTACK(VERIFY/ADD), which traditionally necessitates sacrificing NOPs—a practice deemed unsustainable given the finite number of NOPs available. The suggested mechanism involves utilizing an opcode, tentatively named OP_OP (though alternative names like OP_SETOP or OP_NEXT are under consideration), which would interpret subsequent bytes (e.g., { 0x1521 }) as the new opcode. This method not only conserves NOPs but also introduces a flexible system for opcode extension, albeit at the cost of requiring three bytes for representation.

The proposal acknowledges that most basic functionalities required by users are already addressed by existing opcodes; thus, the addition of new opcodes would primarily focus on fulfilling specific, less frequently needed functions. There's an open question regarding whether to enforce minimal rules for this new opcode system, which could potentially offer a more structured approach versus allowing unrestricted flexibility. Furthermore, it's suggested that unenabled multi-byte opcodes could default to OP_SUCCESS to maintain operational continuity.

This idea represents a shift in focus away from the scarcity of NOPs towards assessing the utility and application scope of potential new opcodes. Despite the innovative nature of this proposal, there's an acknowledgment of the possibility that similar suggestions may have been made previously within the community, albeit hard to trace in the mailing list's history. The proposal invites feedback on this approach, aiming to foster a dialogue on enhancing opcode functionality in a sustainable manner. For more detailed discussions and contributions, interested parties can refer to the original thread on the Bitcoin Development Mailing List, accessible here.