From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZONJ-0008UA-Lu for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 16:34:53 +0000 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; Received: from mail-oa0-f45.google.com ([209.85.219.45]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZONI-0006Ez-S4 for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 16:34:53 +0000 Received: by mail-oa0-f45.google.com with SMTP id o17so3636924oag.4 for ; Mon, 06 May 2013 09:34:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.47.1 with SMTP id z1mr1195114oem.134.1367858087536; Mon, 06 May 2013 09:34:47 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Mon, 6 May 2013 09:34:47 -0700 (PDT) In-Reply-To: References: <20130506161216.GA5193@petertodd.org> Date: Mon, 6 May 2013 18:34:47 +0200 X-Google-Sender-Auth: HiiUrP-Uf3pPRohi6cYpC7-qyG4 Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 X-Headers-End: 1UZONI-0006Ez-S4 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) 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: Mon, 06 May 2013 16:34:53 -0000 > > 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.