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

From: Tom Harding <[email-masked]>
Date: Wed, 06 Aug 2014 07:44:25 -0700

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] 
> <mailto:[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]
>     <mailto:[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.
>