From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VvSZF-0008HY-45 for bitcoin-development@lists.sourceforge.net; Tue, 24 Dec 2013 14:02:41 +0000 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; Received: from outmail148098.authsmtp.com ([62.13.148.98]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VvSZD-0005Ae-Il for bitcoin-development@lists.sourceforge.net; Tue, 24 Dec 2013 14:02:41 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBOE2XrL062725; Tue, 24 Dec 2013 14:02:33 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBOE2T7K010056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Dec 2013 14:02:31 GMT Date: Tue, 24 Dec 2013 09:02:28 -0500 From: Peter Todd To: Jeremy Spilman Message-ID: <20131224140228.GA9838@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 085e8bed-6ca4-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAYUHFAXAgsB AmUbWlBeUF97WmE7 bAxPbAVDY01GQQRq WVdMSlVNFUsqc2N0 BHoZKRlzdwVDfjBx ZURrWD5bVEEvfRQo FlNSRjwCeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zEzMm DzwDBj4oA0AfVm06 KRBuDUARBkIYIy0A X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VvSZD-0005Ae-Il Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Peer Discovery and Overlay X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 14:02:41 -0000 --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/--