On Thu, Jul 18, 2013 at 08:53:55AM -0400, Jeff Garzik wrote: > On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd wrote: > > Note that with OP_DEPTH we can remove the small chance of the payee > > vanishing and putting the funds in limbo: > > What are the costs, benefits, and risks associated with scripts no > longer being stateless, as OP_DEPTH would seem to introduce? Satoshi was worried that in the event of a re-org long chains of transactions could become invalid and thus impossible to include in the blockchain again, however that's equally possibly through tx mutability or double-spends;(1) I don't think it's a valid concern in general. When accepting any payment you need to take the chance of a re-org into account, and if the payment is large enough it'll call for more confirms on that basis. It does increase that (small) risk however and a client may want to trace the transaction chain back a few steps when accepting a very large payment in leu of just waiting for more confirms. 1) Also via non-standard transactions as SetBestChain() calls mempool.accept() which still applies IsStandard(). We also recently broke re-acceptance of transactions with dependencies as they are currently added in reverse order, broken when Matt removed the fIgnoreMissingInputs flag. Not a problem limited to OP_DEPTH either: consider the following probabalistic payment: PREVBLOCKHASH HASH n LESSTHAN VERIFY CHECKSIG Obviously in a re-org the chance of it being succesfully included is slim. (this example is simplistic and is vulnerable to double-spends in a number of ways) Mempool and relay code will have to take into account that a transaction that can be included in the next block may not be possible to include in the block after that for the purposes of protecting against tx-flood DoS attacks - not an important issue unless we loosen IsStandard() -- 'peter'[:-1]@petertodd.org 0000000000000090344430e3956a709039288ceeb473fff6c1b68e70ee7169c4