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
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UZMsY-0007eV-RX
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 14:59:02 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZMsX-0000WV-Vc
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 14:59:02 +0000
Received: by mail-ob0-f179.google.com with SMTP id xn12so3130312obc.24
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 May 2013 07:58:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.47.1 with SMTP id z1mr1091057oem.134.1367852336562; Mon,
06 May 2013 07:58:56 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Mon, 6 May 2013 07:58:56 -0700 (PDT)
Date: Mon, 6 May 2013 16:58:56 +0200
X-Google-Sender-Auth: FwIKcVxE-MbgN2mw8VvPqPVfI-U
Message-ID: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2103ea051ab04dc0df051
X-Spam-Score: -0.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
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1UZMsX-0000WV-Vc
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [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 14:59:03 -0000
--001a11c2103ea051ab04dc0df051
Content-Type: text/plain; charset=UTF-8
Subject change to reflect that this is off-topic for the old thread.
Eventually, I think it makes sense to move to a system where you get seeds
> from
> a DNS (or other mechanism), connect to one or a few of the results, do a
> getaddr,
> fill your peer IP database with it, and disconnect from the DNS seeded
> peer.
This obviously makes no difference from a security perspective. If a DNS
seed is compromised it can feed you nodes that just connect you back to the
sybil. If you seed from DNS then that's your root of trust.
The problem with moving away from DNS seeding for bitcoinj clients at least
is that SPV clients are very sensitive to startup time. It isn't OK to
spend two minutes trying to connect to lots of long-dead IP addresses if
you're wanting to pay your bill in a restaurant. That means either you have
to spin up a lot of TCP connections in parallel, which I know from bitter
experience can cause problems with some crappy wifi routers (they think
it's a synflood), or you get a known fresh source of IPs like a DNS seed
response and then later on bring up connections to the P2P network from
that.
Implementing the latter is complicated - you have to partition your nodes
so the seed peers are separated from the peers you found via addr
broadcasts and seeded peers can't pollute your addr-found peers unless it's
your first run.
I've actually not experimented with this for a while. I'm hoping that by
the time this gets to the top of my todo list, network nodes will be stable
enough that actually you can always obtain at least one or two connections
if you try (say) 30 at once. But I have no idea if we're at that stage yet.
--001a11c2103ea051ab04dc0df051
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Subject change to reflect that this is off-topic for the o=
ld thread.<div><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
Eventually, I think it makes sense to move to a system where you get seeds =
from<br>
a DNS (or other mechanism), connect to one or a few of the results, do a ge=
taddr,<br>
fill your peer IP database with it, and disconnect from the DNS seeded peer=
.</blockquote><div><br></div><div style>This obviously makes no difference =
from a security perspective. If a DNS seed is compromised it can feed you n=
odes that just connect you back to the sybil. If you seed from DNS then tha=
t's your root of trust.</div>
<div style><br></div><div style>The problem with moving away from DNS seedi=
ng for bitcoinj clients at least is that SPV clients are very sensitive to =
startup time. It isn't OK to spend two minutes trying to connect to lot=
s of long-dead IP addresses if you're wanting to pay your bill in a res=
taurant. That means either you have to spin up a lot of TCP connections in =
parallel, which I know from bitter experience can cause problems with some =
crappy wifi routers (they think it's a synflood), or you get a known fr=
esh source of IPs like a DNS seed response and then later on bring up conne=
ctions to the P2P network from that.</div>
<div style><br></div><div style>Implementing the latter is complicated - yo=
u have to partition your nodes so the seed peers are separated from the pee=
rs you found via addr broadcasts and seeded peers can't pollute your ad=
dr-found peers unless it's your first run.</div>
<div style><br></div><div style>I've actually not experimented with thi=
s for a while. I'm hoping that by the time this gets to the top of my t=
odo list, network nodes will be stable enough that actually you can always =
obtain at least one or two connections if you try (say) 30 at once. But I h=
ave no idea if we're at that stage yet.</div>
</div></div></div></div>
--001a11c2103ea051ab04dc0df051--
|
