# Gavin Andresen
# 2011-10-04 13:51:43
# https://bitcointalk.org/index.php?topic=46538.msg557083#msg557083

Wow, so many great ideas! @p{par}

RE: There is already code to warn the user if they are on a minority chain more than 6 blocks long@p{--} see GetWarnings(): @p{brk}

@s{quotedtext}
@s{quotedtext}
 @p{brk}
It just warns, it doesn't stop you from generating/sending transactions. Perhaps if the longer fork is more than 120 blocks ahead it should. @p{par}

ByteCoin: we can prevent the scenario you describe (generate a block with a NOP1/EVAL transaction whose validity is different in old and new clients) by: @p{brk}
1. Requiring that EVAL transactions be valid if the EVAL is interpreted as a no-op.  New clients can replace EVALs with no-ops and re-evaluate them to make sure that is true. @p{brk}
2. Waiting until a majority of hashing power has upgraded before turning on EVAL. @p{par}

gmaxwell:  I really like the idea of implementing key recovery to save space in the block chain. It can also be done in a backwards-compatible way if only CHECKSIGs "hidden inside" of EVALs support it (CHECKSIG would be aware of whether it was being executed inside of an OP_EVAL, and if it was it could use a compressed version of the public key instead of the full public key). @p{par}

All the ideas about figuring out what percentage of miners have upgraded:  seems like that deserves its own discussion thread. @p{brk}