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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rebroad@gmail.com>) id 1SQaUJ-000877-Rg
for bitcoin-development@lists.sourceforge.net;
Sat, 05 May 2012 08:37:12 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=rebroad@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SQaUJ-0002uF-6b
for bitcoin-development@lists.sourceforge.net;
Sat, 05 May 2012 08:37:11 +0000
Received: by wgbfm10 with SMTP id fm10so3273063wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Sat, 05 May 2012 01:37:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.77.233 with SMTP id v9mr19542822wiw.22.1336207025097; Sat,
05 May 2012 01:37:05 -0700 (PDT)
Sender: rebroad@gmail.com
Received: by 10.223.6.18 with HTTP; Sat, 5 May 2012 01:37:05 -0700 (PDT)
Date: Sat, 5 May 2012 09:37:05 +0100
X-Google-Sender-Auth: Mkk7RxGA1hjq1gKoZwhExZQ6rvo
Message-ID: <CAFBxzADtZxJUB49bVzjGdmJoaQnJPMcNhRwpjc=pgRcsMoCQgA@mail.gmail.com>
From: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail.com>
To: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043d646113cbcb04bf45f19e
X-Spam-Score: -0.6 (/)
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
(rebroad[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1SQaUJ-0002uF-6b
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] free tx rate limiter potentially causes more
traffic not less?
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: Sat, 05 May 2012 08:37:12 -0000
--f46d043d646113cbcb04bf45f19e
Content-Type: text/plain; charset=ISO-8859-1
I recently was dabbling with AskFor() and changing the time waited from 2
minutes to 10 seconds (I think perhaps this value may change in future
versions when "network tuning" is implemented).
I noticed that, when used with the -limitfreerelay option that is causes
significant increase in traffic between peers. This is because the tx gets
asked for (from all connected peers usually), but AlwaysHave never becomes
true as it's never stored, always rejected, so it effectively getdatas the
transaction from every single connected peer.
Would it perhaps be better to set up a memory pool for rejected txs and
blocks (perhaps keeping only the hash) so that these rejected items can
continue being ignored?
I hope these observations are ok - I consider myself at the "trying to
understand the code/protocol/algorithm" stage so might sometimes make false
assumptions of what the code intends to do.
Ed
--f46d043d646113cbcb04bf45f19e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I recently was dabbling with AskFor() and changing the time waited from 2 m=
inutes to 10 seconds (I think perhaps this value may change in future versi=
ons when "network tuning" is implemented).<div><br></div><div>
I noticed that, when used with the -limitfreerelay option that is causes si=
gnificant increase in traffic between peers. This is because the tx gets as=
ked for (from all connected peers usually), but AlwaysHave never becomes tr=
ue as it's never stored, always rejected, so it effectively getdatas th=
e transaction from every single connected peer.</div>
<div><br></div><div>Would it perhaps be better to set up a memory pool for =
rejected txs and blocks (perhaps keeping only the hash) so that these rejec=
ted items can continue being ignored?</div><div><br></div><div>I hope these=
observations are ok - I consider myself at the "trying to understand =
the code/protocol/algorithm" stage so might sometimes make false assum=
ptions of what the code intends to do.</div>
<div><br></div><div>Ed</div>
--f46d043d646113cbcb04bf45f19e--
|
