I understand that P2SH transaction types were added "softly" by repurposing a Tx message that is already valid, so old nodes won't reject them in blocks.

Is there a similar method to adding new script OP codes without a hard fork? In other words, how will old nodes interpret "No Op" commands after they have been repurposed for the upgraded protocol?

2 Answers 2


Yes. Before P2SH, the most popular proposal for solving the problem that P2SH solves was OP_EVAL, which did just that: it repurposed OP_NOP1 as OP_EVAL.

A P2SH script looks like this:
[script input...] [serialized script] | OP_HASH160 [script hash] OP_EQUAL
The equivalent OP_EVAL script would look like this to old nodes:
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_NOP1
Old nodes would only check that the serialized script matches the given script hash when hashed. The other stuff would be ignored.

New nodes would see:
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_EVAL
New nodes would understand OP_EVAL, so they'd check that the serialized script matches the given script and execute the serialized script. An OP_EVAL transaction might be seen as invalid for new nodes and valid for old nodes, but not the other way around. That's what makes it a softfork. If the majority of mining power is using the new rules, then this is not a hardfork because the longest chain will always converge to a state that is valid for both old and new nodes.

Depending on the new opcode's behavior, it may be necessary for new nodes to verify scripts twice to ensure that certain scripts can't cause hardforks. Scripts are verified once using the old script rules and once using the new rules.

The OP_EVAL proposal was eventually replaced with P2SH because it was discovered that OP_EVAL accidentally allowed Turing-complete scripts, which the Bitcoin developers didn't want. P2SH is very simple (and a bit weird) in part so that similar accidents would be easy to avoid. But there wasn't any technical problem with this method of adding a new opcode. Moreover, there's nothing restricting the behavior of new opcodes. For example, OP_EVAL could have interpreted its input in a different, Turing-complete language, though there are various reasons why this might not have been a good idea.

  • Thanks Theymos - does this mean that "pay to anyone" transactions are completely replaced by P2SH? Looking at this code blob... github.com/bitcoin/bitcoin/blob/…
    – pinhead
    Nov 3, 2014 at 16:43
  • 1
    @pinhead That code checks whether an output script meets the P2SH pattern and therefore requires additional verification. It seems unrelated to pay-to-anyone transactions. There are many ways of sending an output that anyone can redeem. The standard way is output=OP_TRUE, but any non-zero constant will work. There isn't much point in doing so, but you could use P2SH if you want: OP_HASH160 [hash of OP_TRUE script] OP_EQUAL.
    – theymos
    Nov 3, 2014 at 21:00
  • I guess what I meant was, is it still possible to use OP_HASH160 [HASH OF SOMETHING] OP_EQUAL as an output script if the SOMETHING is not a valid script (could be any data) like, en.bitcoin.it/wiki/Script#Transaction_puzzle
    – pinhead
    Nov 3, 2014 at 23:49
  • 1
    @pinhead No, but if you want to do that you can just add some junk at the start of the script to break the pattern, like OP_0 OP_HASH160 [HASH OF SOMETHING] OP_EQUAL.
    – theymos
    Nov 4, 2014 at 0:28
  • (I just noticed that the script I posted in my previous comment is actually unspendable. Change OP_0 to OP_NOP.)
    – theymos
    Nov 22, 2014 at 22:10

The introduction P2SH didn't mean new OP codes nor repurposing old ones.

You cannot change any existing OP code with a soft fork by definition. The only thing you can do is to interpret information for new applications. For example, you can include the hash of a document to create a proof of existence scheme.

  • 1
    The introduction P2SH didn't mean new OP codes nor repurposing old ones. That's technically true (we didn't repurpose OP_EQUAL, we repurposed OP_HASH160 <data> OP_EQUAL) but it's awfully misleading.
    – Nick ODell
    Nov 2, 2014 at 22:17
  • Nick do you agree with Sortega that OP codes can't be repurposed without a hard fork? Say in the context of adding side chain support?
    – pinhead
    Nov 2, 2014 at 22:48
  • Turning a No-Op into OP_SPVVERIFY, etc
    – pinhead
    Nov 2, 2014 at 22:55
  • 1
    Maybe clarify the answer to point out that a soft fork requires upgraded nodes to comply with the same rules non-upgrade nodes follow, but that the upgraded nodes can also place additional limitations on how an op code is used. For example, op_hash160 <20 bytes> op_equal retained their original meaning for non-upgraded nodes, but upgrade nodes only allowed spending a P2SH scriptPubKey if the spending scriptSig contained a redeemScript that didn't return false. Nov 21, 2014 at 0:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.