Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
	helo=mail-wy0-f175.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 5 Aug 2011 14:03:05 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; )
References: <201108041423.14176.andyparkins@gmail.com>
	<201108051258.25813.andyparkins@gmail.com>
	<1312545969.4516.8.camel@BMThinkPad.lan.bluematt.me>
In-Reply-To: <1312545969.4516.8.camel@BMThinkPad.lan.bluematt.me>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1768847.8MR82ZS5ip";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201108051403.05506.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] Double spend detection to speed up
	transaction trust
Precedence: list

--nextPart1768847.8MR82ZS5ip
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On 2011 August 05 Friday, Matt Corallo wrote:
> On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:
> > I don't really see that "number of connections" is the relevant metric.
>=20
> Number of connections is something that needs serious thought.  Too many
> and you fill everyone's connection slots and no one can make
> connections.  Too few and you don't have a network but just a bunch of
> islands which would also cause serious problems.
> If you aren't relaying, each connection takes almost no bandwidth, so
> the question is how many do you need to be considered secure.

I'm arguing that "number of connection slots" isn't the best metric; so tha=
t=20
wouldn't matter.  Just keep accepting incoming connections (with some sanit=
y=20
limit of course) until you've allocated your bandwidth, not your number of=
=20
connections.

If I connect to a thousand nodes and never send anything, I'm not using up=
=20
very much of their resources.  If _they_ want to use up resources by relayi=
ng,=20
then that is their choice, but again they can do that based on bandwidth=20
calculations rather than connection counts.  If I am sending, then that add=
s=20
to their bandwidth and gets included in whatever limit they've chosen.

=46or example: the client could simply maintain an average bandwidth over a=
ll=20
connections.  If that average is less than threshold0, then make new outgoi=
ng=20
connections.  If that average exceeds threshold1, then stop accepting incom=
ing=20
connections.  If it exceeds threshold2, start dropping established incoming=
=20
connections.  If it exceeds theshold3, start dropping established outgoing=
=20
connections.

The actual rules don't matter so much; I'm just saying bandwidth is a bette=
r=20
metric than connection count.  If you limit by connection count, then you'l=
l=20
just end up filled with non-relaying listeners, since they (in the future)=
=20
will be the most commonplace.  You'll have no incoming relays, and therefor=
e=20
nothing to forward, so your bandwidth will be zero, but your connection cou=
nt=20
at maximum -- you've locked yourself out.



Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart1768847.8MR82ZS5ip
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk476gkACgkQwQJ9gE9xL21McQCeM800bGwT7by8dNlp3T2zanjd
LCYAnRjAdCQC2rrbvt+ypZVAJ+TIgMs0
=V3BY
-----END PGP SIGNATURE-----

--nextPart1768847.8MR82ZS5ip--