public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@exmulti.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Large backlog of transactions building up?
Date: Sun, 23 Sep 2012 16:30:20 -0400	[thread overview]
Message-ID: <CA+8xBpen9o3Oji0ePsbU-ZQCSpFO+tAZt63LaOsR30KULYbUhQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2r6sVC_63xx6U7XLbFkukrFEhq-mGAse3vHJ6nf3Q1cw@mail.gmail.com>

On Sun, Sep 23, 2012 at 8:12 AM, Mike Hearn <mike@plan99.net> wrote:
> Has anyone got long term longs that contain the pool size and timestamps?
>
> Unfortunately I forgot to enable timestamps in the logs for my own
> nodes (the privacy benefit of disabling this by default is
> questionable, imho). But just looking at the general trends and
> cross-checking against my own memory it definitely seems that there
> are more and more pending transactions that don't get cleared into
> blocks.
>
> One of my nodes now routinely has 4000 transactions in the mempool.
> Blocks typically clear only a few hundred at most, which is what you'd
> expect given current transaction rates (around 300 per ten minute
> interval). So what are the other pending transactions doing and why
> aren't they getting drained out of the mempool?

Yeah, my public nodes currently have 2200+  Over time, it gets
cluttered naturally due to the disconnect between what miners mine and
what relayers relay.

I've long argued that all mempool implementations should limit the
lifetime of any TX to a specific number of blocks.  Rationale:
- bitcoin clients retransmit until TX is confirmed
- provides a deterministic lifetime for a TX; if you KNOW a TX will
disappear 144 blocks (24 hours) after you stop transmitting, then it
is probably safe to initiate recovery procedures and perhaps revise
the transaction
- prevents zombie TXs from littering memory... they hang around,
wasting resources, but never get confirmed

No one has strenuously argued against this, so I suppose it is down to
writing a patch, and coming up with a good number we (as a network)
can agree upon.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com



  reply	other threads:[~2012-09-23 20:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-23 12:12 [Bitcoin-development] Large backlog of transactions building up? Mike Hearn
2012-09-23 20:30 ` Jeff Garzik [this message]
2012-09-23 20:44   ` Gregory Maxwell
2012-09-23 21:54     ` Mike Hearn
2012-09-25 17:34       ` Jorge Timón
2012-09-25 17:52         ` Gregory Maxwell

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=CA+8xBpen9o3Oji0ePsbU-ZQCSpFO+tAZt63LaOsR30KULYbUhQ@mail.gmail.com \
    --to=jgarzik@exmulti.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /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