# Gavin Andresen
# 2011-10-02 20:42:32
# https://bitcointalk.org/index.php?topic=46538.msg554620#msg554620

Summary of a discussion @p{(link}that happened in IRC chat this afternoon@p{link)}: @p{par}

There are 10 no-op opcodes that are explicitly for expansion: @p{brk}
  @p{(link}@s{(link)}#L150@p{link)} @p{par}

They are currently enabled, and do nothing. @p{par}

If we did the obvious thing and used one of them for OP_EVAL, then, surprisingly, OP_EVAL would not necessarily cause a block chain split.  Why? @p{par}

Old clients see: @p{brk}
 
Code:
@p{lt}sig@s{gt} @p{lt}...serialized script...@s{gt}  DUP HASH160 @p{lt}hash@s{gt} EQUALVERIFY OP_NOP1
New clients see: @p{brk}
 
Code:
@p{lt}sig@s{gt} @p{lt}...serialized script...@s{gt}  DUP HASH160 @p{lt}hash@s{gt} EQUALVERIFY OP_EVAL
 @p{brk}
Old clients will consider the transaction valid as long as @p{lt}serialized_script@s{gt} hashes to the correct value and is not OP_FALSE, because a script evaluates as valid if it leaves a non-false value on the top of the stack when it is done. @p{par}

New clients will do full validation: the hash has to be right AND the @p{lt}serialized script@s{gt} has to be valid (has to leave a non-false value on the top of the stack). @p{par}

So:  If upgraded clients and miners start producing transactions and blocks with OP_EVAL in them, they will be accepted by old clients and miners as valid. @p{par}

That means OP_EVAL could be supported as soon as 50+% of the network hashing power upgraded, instead of requiring that 100% of the network (clients and miners) upgrade before a certain time or block. @p{par}

Anybody want to volunteer to write a BIP that works through all the details? @p{brk}