Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.45 as permitted sender)
	client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f45.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
	<20130506161216.GA5193@petertodd.org>
	<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
Date: Mon, 6 May 2013 18:34:47 +0200
Message-ID: <CANEZrP12xibOx9jm1fgG=A2PzPf+6G+zrhtWC9+FnJjU2-t_NA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
Precedence: list

> > I've noticed on my Android phone how it often takes quite awhile to find
> > a peer that will actually accept an incoming connection, which isn't
> > surprising really: why should a regular node care about responding to
> > SPV nodes quickly?

I haven't seen that - remote nodes don't have any special code that
knows what kind of client is connecting, so if you're seeing delays I
suspect the issue is elsewhere. For example a seed that is serving
peers which are overloaded, or the general delays inherent to bringing
up a 3G data link from idle (this can take many seconds all by
itself).

I took out Jeffs seed a few weeks ago in git master because it was
often serving nodes that were full, so that should speed things up a
bit. The other seeds all run dynamic crawlers.

There are lots other ways to optimise performance beyond having fresh
seeds, for example, the Android app can (and probably will in future)
support putting Bluetooth MAC addresses in the URLs it serves via
QRcode/NFC. We prototyped it before but didn't finish. That means that
the sending side can provide the receiving side with a transaction via
a local Bluetooth socket, which eliminates the need to wait for P2P
bringup on the send side. In a typical merchant scenario the receive
side is more likely to have WiFi access and is more likely to be
talking to the network frequently, so its list of IPs gathered from
addr packets would be fresher, and it can do P2P bringup whilst the
user is confirming/signing/uploading on the sending side. Overlapping
the two buys precious seconds.