# Gavin Andresen
# 2011-10-06 14:16:05
# https://bitcointalk.org/index.php?topic=46538.msg560045#msg560045

In an effort to keep discussion on track, I split the discussion of Lamport versus Bernstein signature schemes into its own thread. @p{par}

So: can anybody think of any potential attacks that would be enabled by having a standard form: @p{par}


Code:
DUP HASH160 @p{lt}scripthash@s{gt} EQUALVERIFY OP_EVAL
... spent by providing: @p{brk}

Code:
@p{lt}signatures@s{gt} @p{lt}serialized script@s{gt}
 @p{brk}
The simplest @p{lt}serialized script@s{gt} would be @p{lt}pubkey@s{gt} CHECKSIG. @p{par}

 @p{brk}
Things that occur to me or were brought up in the IRC discussion: @p{par}


@p{(li}Denial-of-service if @p{lt}serialized script@s{gt} is allowed to contain OP_EVAL. @p{par}

Proposal on the table is to completely disallow recursion, which eliminates that threat.  I'm tempted to allow limited recursion (max 2 levels deep maybe) because it would allow some really cool things to be done in the future.... @p{brk}
@p{li)}

@p{(li}Stealing coins because old miners/clients will not verify the signature hidden inside @p{lt}serialized script@s{gt}. @p{par}

If 50+% of the hashing power on the network support OP_EVAL, then transactions that pass the @p{lt}scripthash@s{gt} check but fail the signature check inside the @p{lt}serialized script@s{gt} would be accepted as valid by old miners and clients, but would fail to confirm because they would be rejected by the majority of miners. @p{par}

@p{(so}That CANNOT be used to trick exchanges or people using old software, because the old software will not recognize the new script form, and will simply ignore the transaction@p{--} you will @p{(bf}not@p{bf)} get "0/unconfirmed" OP_EVAL transactions displayed in old versions of Bitcoin.@p{so)} Wrong again!  See casacius' excellent response. @p{brk}
@p{li)}

@p{(li}Creating or modifying @p{lt}serialized scripts@s{gt} @p{par}

Maybe there's an attack waiting to happen because an attacker could trigger a buffer overflow bug by doing something like: @p{brk}
@p{lt}safe serialized script@s{gt}  119 OP_ADD  OP_EVAL @p{brk}
But if there is a buffer overflow bug in an implementation's transaction script interpreter, then an attacker can almost certainly just send a "tx" message containing a non-OP_EVAL script that triggers the bug. OP_EVAL certainly does mean one more thing for an implementation to get right, but it isn't actually very hard to implement if you're already able to validate "tx" messages. @p{brk}
@p{li)}
 @p{brk}
Any other attacks anybody can think of? If implementations are strict in which transaction forms they'll accept as "valid AND mine (counts towards my wallet balance)", but liberal in what transaction forms they'll accept as "valid, but I can't spend it" then it seems to me the risks are small. @p{brk}