1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
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 <gmaxwell@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CA+8xBpen9o3Oji0ePsbU-ZQCSpFO+tAZt63LaOsR30KULYbUhQ@mail.gmail.com>
References: <CANEZrP2r6sVC_63xx6U7XLbFkukrFEhq-mGAse3vHJ6nf3Q1cw@mail.gmail.com>
<CA+8xBpen9o3Oji0ePsbU-ZQCSpFO+tAZt63LaOsR30KULYbUhQ@mail.gmail.com>
Date: Sun, 23 Sep 2012 16:44:55 -0400
Message-ID: <CAAS2fgR7yiyTWyuwAqxsnAb-xv9bmBFUxDwJhEkRH1PCP=pzJw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 23 Sep 2012 20:45:05 -0000
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik <jgarzik@exmulti.com> 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!)
|
