Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-06 📝 Original message:...because nLockTime is ...

📅 Original date posted:2014-08-06
📝 Original message:...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 at 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 at 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140806/251779ec/attachment.html>;