So we stop getting pull requests (like #2604) fixing problems with disabled Script opcodes. A hard fork would be required to re-enable these, and if we ever did that we'd require extensive review and testing.
I double-checked to make sure the script_invalid.json unit tests make sure that the disabled opcodes are handled properly (script invalid even if the disabled opcodes are in the unexecuted branch of an OP_IF); they do.
So we stop getting pull requests (like #2604) fixing problems with disabled Script opcodes.
A hard fork would be required to re-enable these, and if we ever did that we'd require extensive review and testing.
Any reason not to remove the definitions of OP_disabledops entirely?
The only reason to keep them would be backward compatibility for the decoded version, I guess, and then even only for very weird scripts...
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/bce697d7faef0d8119ba80ae583cfcce460c7f81 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Good. The code is unused and there is no reason to keep it like this. If it is ever decided to bring the opcodes back, it can be done with better designed semantics w.r.t signed/unsigned handling.
RE: remove opcodes entirely: I thought about removing the OP_ enum constants, but then we'd just have to use hard-coded 0x constants in a couple of places (the early if statement, and the opcode-to-string map so unit tests continued working) which would be uglier and more error-prone.
ACK