Subject: Re: [Bitcoin-development] deterministic transaction expiration

From: Jeff Garzik <[email-masked]>
Date: Wed, 6 Aug 2014 11:08:36 -0400

...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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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/