Re: [Bitcoin-development] deterministic transaction expiration

[Tom Harding <tomh@thinlink.com>]

Having explored more drastic approaches, it looks like Kaz' basic idea 
stands well.  His #1...

> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)

is already implemented in bitcoin-qt #2340, and a "final call" on 
merging it was already sent to this list.  After some thought I agree 
with its policy of eventually setting nLockTime at current-height + 1 by 
default.  This is the "best reasonably expected height" of any tx 
created right now.  It discourages fee-sniping, and if a reorg happens 
anyway, it won't actually delay inclusion of tx beyond the reasonable 
expectation sans reorg.

However right now, #2340 takes a very cautious approach and sets to 
current-height - 10 by default, with randomness to mitigate worries 
about loss of privacy.

Kaz' #2, #3 and #4 are future actions.  #4 only goes most of the way ...

> 4. add a new IsStandard rule rejecting transactions with an nLockTime
> more than N blocks behind the current tip (for some fixed value N, to
> be determined)

... a janitor mechanism is desirable to purge mempool of txes more than 
N behind current-height.

Nodes dropping a tx N blocks after they became eligible to be mined (the 
meaning of nLockTime) makes sense.  It is not an overloading or new use 
for nLockTime, but a logical extension of it.  As Kaz pointed out, this 
solves a big problem with expiring by locally measured age: 
unintentional resurrection.