1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
X-Google-Sender-Auth: HiiUrP-Uf3pPRohi6cYpC7-qyG4
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
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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.
|
