[Bitcoin-development] deterministic transaction expiration
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev