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 < <>> 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 <
    <>> wrote:


        If nLockTime is used for expiration, transaction creator can't
        lie to
        help tx live longer without pushing initial confirmation
        into the future.  Very pretty.  It would also enable "fill or
        transactions with a backdated nLockTime, which must be
        confirmed in a
        few blocks, or start vanishing from mempools.

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.
Bitcoin-development mailing list

Reply via email to