...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 <t...@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 <jgar...@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 <t...@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/
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
