Tom Harding [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-06 📝 Original message:How is eventual expiration ...

📅 Original date posted:2014-08-06
📝 Original message: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
> <mailto: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
> <mailto: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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140806/4326d7ce/attachment.html>;