On 08/06/2014 01:02 PM, Tom Harding wrote: > With first-eligible-height and last-eligible-height, creator could > choose a lifetime shorter than the max, and in addition, lock the whole > thing until some point in the future.
Note that this would be a massive, *massive* change that would completely break bitcoin output frangibility. Merchants would have to start demanding input history back to a certain depth in order to ensure they are not exposing themselves to undue reorg-expiry risk. There are useful applications of a consensus-enforced expiry, particularly within a private (signed block) side chain, and for that reason it is useful to have a discussion about the merits of an nExpiry field or BLOCK_HEIGHT / BLOCK_TIME opcode, and methods for achieving either. However I don't see this ever becoming part of the public bitcoin network. ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
