Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy

[Tom Harding <tomh@thinlink.com>]

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.