Re: [Bitcoin-development] deterministic transaction expiration

[Tom Harding <tomh@thinlink.com>]

On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)

Reorg-frendliness is the opposite of the rationale behind #2340, which 
proposes setting nLockTime at current-height + 1 to prevent 
"fee-sniping" reorgs...


> 2. once users have had some time to upgrade to clients that set
> nLockTime, start discouraging transactions without nLockTime --
> possibly with a slightly higher fee required for relay
> 3. start rate-limiting relay of transactions without an nLockTime
> (maybe this alone could be used to achieve [2])
> 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)
>

One way to proceed is implement #3753 (mempool janitor) in such a way 
that transactions with nLockTime are allowed to live a bit longer in the 
mempool (say 500 blocks) than those without (72 hours).  In other words, 
as a first step, just actually start expiring things from the mempool in 
bitcoin core, and leave any relay fee adjustments or rate limiting for 
later.  The isStandard change would be a good complement to #3753, to 
avoid relaying a tx that will soon expire by the nLockTime rule anyway.