Probably the most interesting thing in testing this stuff is coming up with uses for them. Doing so would guide which ones were more important to add. (and this is key: it should probably be thought of as _add_ not re-enable, since adding can be done as a soft fork, a lot easier and less risky)
You mean using nops? My understanding is that a script containing a disabled opcode will fail.
Maybe it could work like the P2SH code.
Pub key:
<script - version> <ignore> <actual script> OP_EXECUTE OP_DROP OP_DROP OP_DUP OP_HASH160 <hash of address> OP_EQUAL_VERIFY OP_CHECKSIG
sig script
<hash of public key>
<signature>
<hashes for actual script>
This means that old clients won't allow spending unless you have the standard public key.
Colored coins would still want to make sure that the spend is authorized, so the <actual script> would .
New clients would run the actual script too.
The rules could be something like
- reject script if <script - version> of any output is not a network accepted version
- reject script if it has more than 1 OP_EXECUTE opcode
- run <actual script> with 2 + <ignore> items popped off the stack (2 + 2 in this case)
-- transaction is invalid if this script fails
This would need to be combined with a rule for updating the script number.
For example, if 550 out of 1000 blocks have /SCV+<n>/ in their coinbase transactions, then from 2000 blocks later, scripts of that version would be allowed. If there is 55 out 100 with </SCV-<n>/, then that disables that script version.
The rule for miners would be to not include any transactions that they cannot verify in their own blocks. A warning would also be given recommending upgrading.