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:
scriptPubKey:
OP_HASH160 0x14 {data} OP_EQUAL
Is equivalent to:
scriptPubKey:
0x01 0xa9 OP_METAOP 0x14 {data} 0x01 0x87 OP_METAOP
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:
scriptPubKey:
0xba OP_HASH160 0x14 {data} OP_EQUAL
Is NOT equivalent to:
scriptPubKey:
0x01 0xba OP_METAOP OP_HASH160 0x14 {data} OP_EQUAL
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.
