Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TFt33-0000Oj-15 for bitcoin-development@lists.sourceforge.net; Sun, 23 Sep 2012 20:45:05 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.175 as permitted sender) client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f175.google.com; Received: from mail-ie0-f175.google.com ([209.85.223.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TFt2z-0002oz-2r for bitcoin-development@lists.sourceforge.net; Sun, 23 Sep 2012 20:45:04 +0000 Received: by iebc13 with SMTP id c13so2038756ieb.34 for ; Sun, 23 Sep 2012 13:44:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.186.196 with SMTP id fm4mr3602156igc.8.1348433095763; Sun, 23 Sep 2012 13:44:55 -0700 (PDT) Received: by 10.64.34.4 with HTTP; Sun, 23 Sep 2012 13:44:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 23 Sep 2012 16:44:55 -0400 Message-ID: From: Gregory Maxwell To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.1 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TFt2z-0002oz-2r 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:45:05 -0000 On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik wrote: > 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. Right, this disconnect is why simple scalar measures of mempool size aren't terribly informative. There are bursts of weird transactions (e.g. someone was flooding zero value txn a few weeks ago; before that there were some enormous series of double-spend induced orphans), and other sustained loads that quite a few miners are intentionally excluding. > 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. Sounds good=E2=80=94 my only concern is that nodes will repeat their own transactions but not the unconfirmed parents. So being more aggressive can turn otherwise valid transactions into orphans. Would there be value in an archive-mempool which is only checked when you receive an orphan transaction? I would point out that you can't _KNOW_ a txn will disappear. Someone else could happily reannounce it. (I know you know this; but it's good to be clear on that point when we talk about it!)