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 <jgarzik@bitpay.com 
> <mailto:jgarzik@bitpay.com>> 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 <tomh@thinlink.com
>     <mailto:tomh@thinlink.com>> 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.
>