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; 
MIME-Version: 1.0
Sender: rebroad@gmail.com
Date: Sat, 5 May 2012 09:37:05 +0100
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] free tx rate limiter potentially causes more
	traffic not less?
Precedence: list

--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 &quot;network tuning&quot; 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&#39;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 &quot;trying to understand =
the code/protocol/algorithm&quot; stage so might sometimes make false assum=
ptions of what the code intends to do.</div>
<div><br></div><div>Ed</div>

--f46d043d646113cbcb04bf45f19e--