Redefining opcodes and OP_EVAL proposal

[piuk]

I haven't been following that closely so this maybe completely off target.

In the OP_EVAL proposal it states that OP_NOP1 will be redefined as OP_EVAL. My question is what happens to scripts that already contain this op code?

For example say I made an output with a scriptPubKey as follows:

OP_DUP OP_HASH160 dd1a6a4549838b5abff214c81e4b2aba7ddd550c OP_NOP1 OP_EQUALVERIFY OP_CHECKSIG

Currently I think this script would validate (and may even pass isStandard()?). But when the new proposal comes in OP_NOP1 will be redefined as OP_EVAL and the script will no longer validate.

If this script was included in the blockchain then validation would fail for new clients during the initial blockchain download.

[1714160405]

1714160405

[1714160405]

1714160405

[1714160405]

1714160405

[makomk]

Currently I think this script would validate (and may even pass isStandard()?). But when the new proposal comes in OP_NOP1 will be redefined as OP_EVAL and the script will no longer validate.

If this script was included in the blockchain then validation would fail for new clients during the initial blockchain download.

The plan was to only treat OP_NOP1 as OP_EVAL for blocks with timestamps after the switch-on time, and to make sure that well over 50% of miners will know to reject blocks containing such scripts by that time. OP_EVAL is probably going to be replaced by a different proposal, but that uses the same approach to dealing with transactions which are valid under the old rules but not the new.

[genjix]

Status: Withdrawn