# Gavin Andresen
# 2011-10-19 21:04:22
# https://bitcointalk.org/index.php?topic=46538.msg583802#msg583802

@s{quotedtext}
@s{quotedtext}
 @p{brk}
Yes. Although there might be a way of accomplishing the same thing without recursion: @p{par}

Use case: @p{par}

Imagine we want, in the future, to support "this" OR "that" transactions.  Where "this" and "that" are themselves possibly complex multisignature or escrow or whatever transactions. @p{par}

Most straightforward way might be a new standard transaction that looks like: @p{par}


Code:
DUP HASH160 @p{lt}hash160@s{gt} EQUAL @p{brk}
IF @p{brk}
  OP_EVAL      "evaluate the this" @p{brk}
ELSE @p{brk}
 DUP HASH160 @p{lt}hash160@s{gt} EQUALVERIFY @p{brk}
 OP_EVAL       "... or evaluate the that" @p{brk}
ENDIF @p{brk}

 @p{brk}
So you'd redeem it by putting one script or the other on the stack (along with the signatures needed by the script). @p{par}

So.... maybe you want to recurse so that the IF/ELSE script is @p{(bf}itself@p{bf)} part of a standard, single-hash OP_EVAL, so you can use a newfangled bitcoin address to send to it.  That would look like: @p{par}


Code:
scriptSig:  @p{lt}signatures@s{gt} @p{lt}this_or_that_script@s{gt} @p{lt}IF/ELSE script@s{gt} @p{brk}
scriptPubKey:  DUP HASH160 @p{lt}hash of IF/ELSE script@s{gt} EQUALVERIFY OP_EVAL @p{brk}

 @p{brk}
I am NOT proposing an IF/ELSE "this or that" standard script type; I think there is plenty of enough work to do to actually make secure wallets and in-the-chain escrow work.  But supporting limited recursion for non-standard or future transactions seems easy and safe... @p{par}

(terminology footnote:  calling scriptSig+scriptPubKey "transactions" isn't accurate, the transaction is the bigger thing, but I'm not sure what else to call them; I hope y'all follow what I'm saying)