Topic: Proposal: Soft-fork to extend the set of NO-OP opcodes (Read 575 times)

I think there is a way that we can extend the NO-OP set to beyond just 0xb0-0xb9. I'm not sure why it was kept so small anyway, when 0xba-0xf8 are not really being used. It basically involves making a one-time soft fork to change one of the currently unused NO-OPs to be OP_METAOP. OP_METAOP is similar to the proposed OP_EVAL, but simpler as it can only execute one opcode, not a whole script. If the name doesn't give it away already, I think an example will most clearly describe what it does:


OP_METAOP basically means take the byte (maybe even bytes, someday) that was just pushed onto the stack and interpret it as an OP_CODE. When an opcode is executed through the use of the OP_METAOP, however, it is executed in a new context -- a context which extends the set of NO-OPs. So, while the two scripts above would produce the same results, the two below will not:


These are not equivalent because un-upgraded nodes will refuse the first but allow the second. In the first one, the opcode 0xba executed directly is invalid, but when executed through OP_METAOP there is further context that can tell the script interpreter when it is okay to execute this OP differently. When evaluating scripts that use OP_METAOP, un-upgraded nodes just ignore it and execute the rest of the script, so it's a soft fork.

And theoretically, if we needed to extend the opcode set again, another one of the (original) unused opcodes could be changed to OP_METAMETAOP and behave in the same way as OP_METAOP but provide another differentiating context to interpret opcodes differently. However, fully backwards compatible OP_META*OP abstractions have to use one of the original 0xb0-0xb9 OP_NOPs. OP_METAOP could possibly even be used to extend the opcode set beyond the 1 byte range, I believe. Why did satoshi only give us 10 OP_NOPs anyway?

I know of these planned/proposed uses for some of the OP_NOPs. With 4/10 already being planned for use, OP_METAOP could be useful to extend the OP_NOP set.

• OP_CHECKLOCKTIMEVERIFY
• OP_RELATIVECHECKLOCKTIMEVERIFY
• OP_SCHNORRCHECKSIG
• OP_SCHNORRCHECKSIGVERIFY

(Sidenote: maybe this type of setup could be used to version the opcodes. So, define OP_V1EXEC to be execute the top byte as bitcoin executes them now, then use another to OP_V2EXEC to use a modified rule set.)

Other considerations:

• I think there would have to be some serous IsStandard() constraints on these OPs.
• Script analyzation for signature check counting may get messy... but not as messy as OP_EVAL. Using OP_METAOP within OP_METAOP should probably be dis-allowed to make script analyzation less error-prone.
• Scripts that use the OP_METAOP in an improperly formatted way should fail, just like other ops fail if used incorrectly.

If this proposal is received well (and not old-news, I think it's impossible to keep up with every idea in the crypto-currency space), I'll begin working on a pull request.