Reading through the wiki (bitcoin.it consensus versions) I noticed that release 0.3.7 ("scriptSig + scriptPubKey evaluations separated") is listed as a hard-forking change. In BitMEX's account of consensus forks, the same version is described as "potentially a non-deterministic hardfork". I would like to understand the rationale for this description.

In previous versions to 0.3.7, the scriptSig was concatenated to the scriptPubKey, and also allowed executable opcodes (such as OP_RETURN, at the time when it finished the script's execution without failing, allowing for the OP_1 OP_RETURN bug). The commit with the changes can be found here.

I guess disabling OP_RETURN can be considered a soft-fork, because previously valid transactions are now invalid. But I cannot come up with any example of a transaction, previously invalid, that would become valid after separating the evaluation of the scriptSig and scriptPubKey. The best I have come up with (with the old meaning of OP_RETURN in mind) is:

scriptSig: OP_2 (push the next 2 bytes to the stack)

Evaluated together, OP_1 OP_RETURN would be pushed to the stack as data instead of evaluated, therefore failing the script after OP_FALSE. However, when evaluated separately, the scriptPubKey would pass as valid (... but not the scriptSig, for providing no data to push?).

Thank you

2 Answers 2


Yes. An invalid pair of arguments to CHECKSIG can become valid after the fork. This is because the scriptSig is evaluated too.

scriptPubKey: OP_TRUE
scriptSig: <sig> <pubkey> OP_CHECKSIGVERIFY

Before the fork, sig would be checked with a scriptCode containing the concatenation of the scriptSig, a CODESEPARATOR, and the scriptPubKey.
After the fork, sig would be checked with a scriptCode containing only the scriptSig itself.

Therefore the hashes differ and a signature could be valid after the fork whereas it was invalid before.


I haven't tested it, but perhaps scripts using the alt stack (which IIRC is cleared with the split execution)?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy