[Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

Gregory Maxwell gmaxwell at gmail.com
Wed Feb 19 21:05:03 UTC 2014


dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd <pete at 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).




More information about the bitcoin-dev mailing list