{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-19\n📝 Original message:dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e 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.\n\nFor some reason it took me a couple reads to get this so I thought I'd\nrestate it in a more blunt form.\n\nThere may exist people today who have send funds to addresses,\nauthored nlocktime releases, and destroyed the key the funds are at\nnow in order to achieve a timelock.  This might be a foolish thing to\ndo, but it's the kind of thing that you have to worry about when\npotentially breaking existing transactions.\n\n(This kind of us is, fwiw, another example of why ANYONE_CAN_PAY is useful)."}