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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1QW3zW-0008DC-SC
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jun 2011 10:03:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.182 as permitted sender)
client-ip=209.85.216.182;
envelope-from=decker.christian@gmail.com;
helo=mail-qy0-f182.google.com;
Received: from mail-qy0-f182.google.com ([209.85.216.182])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QW3zR-00012s-F1
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jun 2011 10:03:30 +0000
Received: by qyk27 with SMTP id 27so3007281qyk.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 Jun 2011 03:03:20 -0700 (PDT)
Received: by 10.229.29.20 with SMTP id o20mr3598879qcc.181.1307957933122; Mon,
13 Jun 2011 02:38:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.247.6 with HTTP; Mon, 13 Jun 2011 02:38:13 -0700 (PDT)
In-Reply-To: <BANLkTimDGr-yX9zgS3qWPZALprWCsFieXg@mail.gmail.com>
References: <BANLkTin_qs4bDabnu+b3K1hTzLzr4JKHsg@mail.gmail.com>
<BANLkTimDGr-yX9zgS3qWPZALprWCsFieXg@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Mon, 13 Jun 2011 11:38:13 +0200
Message-ID: <BANLkTi=oYjydw7sT=sqSN3sHMhM+pq=c6w@mail.gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=0016364271d6fc244e04a594af4f
X-Spam-Score: -0.6 (/)
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 freemail
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QW3zR-00012s-F1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bootstrapping via BitTorrent trackers
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, 13 Jun 2011 10:03:31 -0000
--0016364271d6fc244e04a594af4f
Content-Type: text/plain; charset=ISO-8859-1
Don't get me wrong, DNS Seeding is an excellent way to bootstrap via trusted
nodes, I'm not trying to replace it.
What I'm trying to get rid of is the IRC bootstrapping and the hardcoded
nodes in the client, they're easy targets.
BitTorrent trackers are used to handle several thousands of requests, so
they would probably scale well enough. I'm not even talking about using the
DHT trackers, but using old fashioned HTTP based trackers. The fact that
each bitcoin client would contact the tracker would make it very hard for an
attacker to get bootstrapping clients to exclusively connect to his
compromised clients. I would say that using a tracker such as OpenBittorrent
provides the same advantages as using an IRC channel.
On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker
> <decker.christian@gmail.com> wrote:
> > We have quite a few bootstrapping mechanisms, starting with the overly
> > complex (IMHO) IRC bootstrapping, which is often suspected as
> bot-activity.
> > Then we have a few hardcoded nodes and some fallback nodes. I was
> wondering
> > why we didn't adopt BitTorrent tracker bootstrapping until now? It's
> > basically all it does. Given a hash (SHA1 hash of the genesis bloc would
> be
> > nice ^^) it gives you a list of other nodes with the same hash.
>
> It seems to offer few benefits over DNS seeding, while potentially
> potentially creating a vulnerable hot spot in the DHT. Sybil attacks
> on DHTs are well documented.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
--0016364271d6fc244e04a594af4f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Don't get me wrong, DNS Seeding is an excellent way to bootstrap via tr=
usted nodes, I'm not trying to replace it.<br>What I'm trying to ge=
t rid of is the IRC bootstrapping and the hardcoded nodes in the client, th=
ey're easy targets.<br>
<br>BitTorrent trackers are used to handle several thousands of requests, s=
o they would probably scale well enough. I'm not even talking about usi=
ng the DHT trackers, but using old fashioned HTTP based trackers. The fact =
that each bitcoin client would contact the tracker would make it very hard =
for an attacker to get bootstrapping clients to exclusively connect to his =
compromised clients. I would say that using a tracker such as OpenBittorren=
t provides the same advantages as using an IRC channel.<br>
<br><div class=3D"gmail_quote">On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzi=
k <span dir=3D"ltr"><<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmu=
lti.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker<br>
<<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gmail.co=
m</a>> wrote:<br>
> We have quite a few bootstrapping mechanisms, starting with the overly=
<br>
> complex (IMHO) IRC bootstrapping, which is often suspected as bot-acti=
vity.<br>
> Then we have a few hardcoded nodes and some fallback nodes. I was wond=
ering<br>
> why we didn't adopt BitTorrent tracker bootstrapping until now? It=
's<br>
> basically all it does. Given a hash (SHA1 hash of the genesis bloc wou=
ld be<br>
> nice ^^) it gives you a list of other nodes with the same hash.<br>
<br>
</div>It seems to offer few benefits over DNS seeding, while potentially<br=
>
potentially creating a vulnerable hot spot in the DHT. =A0Sybil attacks<br>
on DHTs are well documented.<br>
<font color=3D"#888888"><br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
</font></blockquote></div><br>
--0016364271d6fc244e04a594af4f--
|
