dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd <p...@petertodd.org> wrote: > While we might be able to get away with a retroactive change in meaning right > now in the future that won't be so easy. There are lots if proposed > applications for nLockTime-using protocols that depend on transactions (or > parts of transactions) being possible to mine as is. Making existing > transactions impossible to mine in the future will break those types of > applications. We might as well use this as a learning experience for what a > version bump would look like infrastructures wise.
For some reason it took me a couple reads to get this so I thought I'd restate it in a more blunt form. There may exist people today who have send funds to addresses, authored nlocktime releases, and destroyed the key the funds are at now in order to achieve a timelock. This might be a foolish thing to do, but it's the kind of thing that you have to worry about when potentially breaking existing transactions. (This kind of us is, fwiw, another example of why ANYONE_CAN_PAY is useful). ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
