On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote: > On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock <b...@mattwhitlock.name> wrote: > > It would make more sense to introduce a new script opcode that pushes the > > current block height onto the operand stack. Then you could implement > > arbitrary logic about which blocks the transaction can be valid in. This > > would require that the client revalidate all transactions in its mempool > > (really, only those making use of this opcode) whenever the chain tip > > changes. > > Transactions that become invalid later are have pretty severe > consequences because they might mean that completely in an absence of > fraud transactions are forever precluded due to a otherwise harmless > reorg.
I understand what you're saying, but I don't understand why it's a problem. Transactions shouldn't be considered "final" until a reasonable number of confirmations anyway, so the possibility that an "accepted" transaction could become invalid due to a chain reorganization is not a new danger. Ordinary transactions can similarly become invalid due to chain reorganizations, due to inputs already having been spent in the new branch. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
