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 <jeremy@taplink.co>) id 1VvNjO-0006Ke-Oa
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Dec 2013 08:52:50 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
	designates 50.117.27.232 as permitted sender)
	client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
	helo=mail.taplink.co; 
Received: from mail.taplink.co ([50.117.27.232])
	by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1VvNjM-0000o7-Tf for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Dec 2013 08:52:50 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
	mail.taplink.co ; Tue, 24 Dec 2013 00:52:57 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Date: Tue, 24 Dec 2013 00:52:46 -0800
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w8k9l8qayldrnw@laptop-air.hsd1.ca.comcast.net>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -2.1 (--)
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.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-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
	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: taplink.co]
X-Headers-End: 1VvNjM-0000o7-Tf
Subject: [Bitcoin-development] Peer Discovery and Overlay
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: Tue, 24 Dec 2013 08:52:50 -0000

Some really nice efforts out there to map and analyze the bitcoin P2P  
network.

The current protocol apparently recommends returning up to 2500 addresses  
 from 'getaddr'. I'm not sure how much clients are expected to probe the  
address space in order to select 'far-apart' peers, or how much such an  
process would even attempt to achieve.

How much does it matter if the ability to discover the entire network of  
peers is fast or slow? There are probably pros and cons to both.

Is there any thought to how existing bitcoin node relations, and the ease  
at which peers can be discovered, becomes a service in itself, or even  
possibly a vulnerability?

Are there any past instances of applications hijacking or interfacing with  
the exiting p2p messages, or abusing 'getaddr' functionality? Are there  
any guidelines on this, or should there be?