Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.98 as permitted sender)
	client-ip=62.13.148.98; envelope-from=pete@petertodd.org;
	helo=outmail148098.authsmtp.com; 
Date: Tue, 24 Dec 2013 09:02:28 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20131224140228.GA9838@savin>
References: <op.w8k9l8qayldrnw@laptop-air.hsd1.ca.comcast.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <op.w8k9l8qayldrnw@laptop-air.hsd1.ca.comcast.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Peer Discovery and Overlay
Precedence: list


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 24, 2013 at 12:52:46AM -0800, Jeremy Spilman wrote:
> Some really nice efforts out there to map and analyze the bitcoin P2P =20
> network.
>=20
> The current protocol apparently recommends returning up to 2500 addresses=
 =20
>  from 'getaddr'. I'm not sure how much clients are expected to probe the =
=20
> address space in order to select 'far-apart' peers, or how much such an =
=20
> process would even attempt to achieve.

The logic is that by simply connecting to peers at random you keep the
network structure as a whole randomized. You don't need to make any
specific attempt at connecting to "far-apart" peers.

> How much does it matter if the ability to discover the entire network of =
=20
> peers is fast or slow? There are probably pros and cons to both.
>=20
> Is there any thought to how existing bitcoin node relations, and the ease=
 =20
> at which peers can be discovered, becomes a service in itself, or even =
=20
> possibly a vulnerability?

Keep in mind it's easy for better knowledge of the network to be a
vulnerability; the number of full nodes is small enough that DoS
attacking all of them is quite feasible.

The other big vulnerability is that getaddr data is best effort; we
currently have no mechanism to ensure that nodes are in fact operated by
separate individuals. It'd be quite easy for someone to set up a
relatively small number of nodes that only advertise themselves in the
getaddr information. Over time they would get proportionally more
incoming connections than is "fair"

As for node addresses being a service, that's what the DNS seeds are!
bitcoinj clients, for instance, depend very heavily on those seeds and
can be easily compromised in a variety of ways by them.

--=20
'peter'[:-1]@petertodd.org
000000000000000092a315c01cfc115d7f1b40dc44edbafd504b0d7498b0704a

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQGrBAEBCACVBQJSuZP0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDBiYTY3NmVkZjY1ZGNiZWZjOGQxNTVkMDU5NzNmMWIwYTlm
ZGM5MDgxMDg1NzllZGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuUUwf+PpnVivHqC9l/OpqW8k4wgqu/
Si9YU9YuADT1HhXd5xIqdeR8V/4W7gvW/JZ2XeCMP+TttNOcvlWZAmdrekOGedTQ
6vJmtHTPh5RZDH9niY7niRDgeyAZXD2EJOr+LkSpnqooIx+4bPJwvtcuEIiIpnsq
/siKMXQh7x3vEh6ceYvBxy6Nz9gGji9xJi6Fvfb9KdKFtxCjDHySJUI+nIEkia/s
4cC7D8ene4CC1yAz5nfCUXqZKuz83++Nr0CbyfVCemPkeTRLMe6ufrJ+qGctiORG
gakkNbr3ltDG3RoToTD5NUnHUQCeA6dmNfQpzV2EV2myJ+5KAWSfUj488KpfFQ==
=PLvW
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--