[Bitcoin-development] deterministic transaction expiration

Tom Harding tomh at thinlink.com
Wed Aug 6 14:44:25 UTC 2014

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>

More information about the bitcoin-dev mailing list