Message-ID: <55A7E0F2.2030400@thinlink.com>
Date: Thu, 16 Jul 2015 09:50:58 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <55A5A837.1090203@thinlink.com>
	<2272402.KPsXmgHuuj@coldstorage>	<55A6E98C.3090307@thinlink.com>
	<2509294.8eWsy7oNj2@coldstorage>
In-Reply-To: <2509294.8eWsy7oNj2@coldstorage>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy
Precedence: list

On 7/16/2015 2:38 AM, Thomas Zander via bitcoin-dev wrote:
> On Wednesday 15. July 2015 16.15.24 Tom Harding via bitcoin-dev wrote:
>> On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote:
>>> On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote:
>>>> Rule 2: A transaction and its dependents are evicted on its 2-hour
>>>> anniversary, whether space is required or not
>>> Instead of 2 hours, why not a number of blocks?
>> So users/wallets can know when they should rebroadcast and consider
>> increasing the fee.
>>
>>
>> Using 12 blocks, there is a 5% chance he has to wait 3 hours.*
>>
>> Using 120 minutes, there is only a .23% chance that fewer than 4 blocks
>> have occurred.**
> Using the good old saying; results in the past are no indication of the
> future.
> I see a logic error in your thinking.
>
> Your assumption that time is a better indicator is false. Naturally time
> itself is universal, but blocks are known by wallets too. Its just as good.
>
> This assumption of yours leans heavily on block mining times, and that is
> not guaranteed in the future.  Imagine one day half the miners dropping and
> blocks take much longer for a week or so.  Your assumptions just broke the
> mempool.
>

It's not a question of right vs. wrong.  Either method has consequences 
for user expectations and behavior.

With fixed-block mempool expiration, the expiration time is variable.  
User can get an alert, but at an unpredictable time.

With fixed-timeout, the likelihood of expiration is more variable 
(expiration occurrence is unpredictable regardless), but any expiration 
will occur at the timeout.