From: Mike Hearn <mike@plan99•net>
To: Jeff Garzik <jgarzik@exmulti•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Mon, 6 May 2013 18:34:47 +0200 [thread overview]
Message-ID: <CANEZrP12xibOx9jm1fgG=A2PzPf+6G+zrhtWC9+FnJjU2-t_NA@mail.gmail.com> (raw)
In-Reply-To: <CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
> > 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.
next prev parent reply other threads:[~2013-05-06 16:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn [this message]
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back
2013-05-07 12:04 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP12xibOx9jm1fgG=A2PzPf+6G+zrhtWC9+FnJjU2-t_NA@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@exmulti$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox