...because nLockTime is the exact opposite of expiration. A locked TX begins life invalid, and becomes valid (not-expired) after nLockTime passes. A new field containing expiration time would work. On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding wrote: > > How is eventual expiration of a tx that started life with an nLockTime in > the future "breaking", any more than any other tx expiring? > > > > On 8/6/2014 6:54 AM, Mike Hearn wrote: > > We could however introduce a new field in a new tx version. We know we > need to rev the format at some point anyway. > > > On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik wrote: > >> ...and existing users and uses of nLockTime suddenly become worthless, >> breaking payment channel refunds and other active uses of nLockTime. >> >> You cannot assume the user is around to rewrite their nLockTime, if it >> fails to be confirmed before some arbitrary deadline being set. >> >> >> >> On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding wrote: >> >>> ... >>> >> > If nLockTime is used for expiration, transaction creator can't lie to >>> help tx live longer without pushing initial confirmation eligibility >>> into the future. Very pretty. It would also enable "fill or kill" >>> transactions with a backdated nLockTime, which must be confirmed in a >>> few blocks, or start vanishing from mempools. >>> >> > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/