From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TFsow-0008I5-Gv for bitcoin-development@lists.sourceforge.net; Sun, 23 Sep 2012 20:30:30 +0000 X-ACL-Warn: Received: from mail-qc0-f175.google.com ([209.85.216.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TFsos-00061C-6Z for bitcoin-development@lists.sourceforge.net; Sun, 23 Sep 2012 20:30:30 +0000 Received: by qcad10 with SMTP id d10so4025431qca.34 for ; Sun, 23 Sep 2012 13:30:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iNqqj/aAOveEBrj/cpGieUixahRLsH92oeeRUx1L0M0=; b=K5RNlEhpQg9gMsY/dgfNEiAWwI4Ee0LHO/jLjCmIOFrue6gw0q8AIqOi4s9ySvup20 GxdQlR4+gEWa6wHcCpq7rBN/AZ0UCQOg95zr0Y9kZETneNmxCdb1Gm8DjWqV+lzTcqRh xkwjE/LzPYgdSpdDTi87opmJR/UvYU2ab/chatdc/IbviuxSXM6lJRwqzVEnUEbfhpuW XzQFbtb6m8bNW6itxu0Sx+Vo0meC4o708xtEkz4glH0SDlVSLFVsw94yCk32g70RrI7Y 6KYwI1T4dnnMd1wolN1oOdu8BwCraer/XguoJotHXisSiI6SjSgdhlRiz9MlbG5fq0CV zF8Q== MIME-Version: 1.0 Received: by 10.224.213.10 with SMTP id gu10mr28105688qab.10.1348432220676; Sun, 23 Sep 2012 13:30:20 -0700 (PDT) Received: by 10.49.97.6 with HTTP; Sun, 23 Sep 2012 13:30:20 -0700 (PDT) X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2] In-Reply-To: References: Date: Sun, 23 Sep 2012 16:30:20 -0400 Message-ID: From: Jeff Garzik To: Mike Hearn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnIZXGQi6pOfww6BdJ1h+kW/UDfSEDVXSTMNK480G0NRriTrsD7VLJ90LXmUS9X+9stqIAF X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1TFsos-00061C-6Z Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Large backlog of transactions building up? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 20:30:30 -0000 On Sun, Sep 23, 2012 at 8:12 AM, Mike Hearn 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