Message-ID: <53E1A8AF.4030206@thinlink.com>
Date: Tue, 05 Aug 2014 21:01:51 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>	<CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>
	<CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
In-Reply-To: <CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

On 8/5/2014 12:10 PM, Kaz Wesley wrote:
> Any approach based on beginning a transaction expiry countdown when a 
> transaction is received (as in mempool janitor) seems unviable to me: 
> once a node has forgotten a transaction, it must be susceptible to 
> reaccepting it;

It's hard to argue with that logic.

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.