Re: [Bitcoin-development] deterministic transaction expiration

[Jeff Garzik <jgarzik@bitpay.com>]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

 ...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 <tomh@thinlink.com> 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 <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> 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/

[-- Attachment #2: Type: text/html, Size: 4194 bytes --]