public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Harding <tomh@thinlink.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy
Date: Thu, 16 Jul 2015 09:50:58 -0700	[thread overview]
Message-ID: <55A7E0F2.2030400@thinlink.com> (raw)
In-Reply-To: <2509294.8eWsy7oNj2@coldstorage>

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.




      reply	other threads:[~2015-07-16 16:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15  0:24 [bitcoin-dev] Mempool "Expected Byte Stay" policy Tom Harding
2015-07-15 19:18 ` Thomas Zander
2015-07-15 23:15   ` Tom Harding
2015-07-16  9:38     ` Thomas Zander
2015-07-16 16:50       ` Tom Harding [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A7E0F2.2030400@thinlink.com \
    --to=tomh@thinlink.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox