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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <michael@ndrix.org>) id 1Rs5P3-0006e6-Gf
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 04:33:09 +0000
X-ACL-Warn:
Received: from out3-smtp.messagingengine.com ([66.111.4.27])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Rs5P2-0003CM-I4
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 04:33:09 +0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D112220F6A
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 23:33:02 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
by compute1.internal (MEProxy); Mon, 30 Jan 2012 23:33:02 -0500
X-Sasl-enc: o7iC7JBRu7C237LGhOcfFt0jeIpFElMoHTuXbCcdY9cP 1327984382
Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com
[209.85.216.54])
by mail.messagingengine.com (Postfix) with ESMTPSA id A34668E0169
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 23:33:02 -0500 (EST)
Received: by qaea17 with SMTP id a17so3449360qae.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 20:33:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.174.76 with SMTP id s12mr25371476qaz.11.1327984382467;
Mon, 30 Jan 2012 20:33:02 -0800 (PST)
Received: by 10.229.238.147 with HTTP; Mon, 30 Jan 2012 20:33:02 -0800 (PST)
In-Reply-To: <CABsx9T0avsrL3134WaA3boG-cdx2NcgEH1mQG7Cef78ZV5UNkw@mail.gmail.com>
References: <CAPg+sBjNTS3n8Q3XzZi5GpBL6k_-4AxRKr0BkWa=-AAVgqS=2Q@mail.gmail.com>
<CAFHuXub52Lu4T0mCWoPoCrHGhCXyLpmEpSWn32_PZPjaRGL2LQ@mail.gmail.com>
<CABsx9T0avsrL3134WaA3boG-cdx2NcgEH1mQG7Cef78ZV5UNkw@mail.gmail.com>
Date: Mon, 30 Jan 2012 21:33:02 -0700
Message-ID: <CAFHuXuZ78y3nHfuKBgjO1j+bNsdnbngDee_Xii4xGhUshJqtZQ@mail.gmail.com>
From: Michael Hendricks <michael@ndrix.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
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: 1Rs5P2-0003CM-I4
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
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: Tue, 31 Jan 2012 04:33:09 -0000
On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen <gavinandresen@gmail.com> w=
rote:
> Given the randomness in Pieter's design, that seems extremely unlikely
> / difficult to do. Is it possible to do a back-of-the-envelope
> calculation to figure out what percentage of nodes on the network an
> attacker would have to control to have a (say) 1% chance of a
> successful Sybil attack?
The randomness prevents finely crafted attacks since an attacker can't
predict which bucket his address ends up in. I don't think it helps
against brute force attacks though. If 60% of the network's nodes are
controlled by an evil botnet, 60% of the nodes we pull out of the
address manager point to the attacker. If a client has 8 connections
to the network, a Sybil attack would succeed 1.7% of the time. At
current network size, 60% of listening nodes is 2,800; only 2-5% of a
decent botnet.
Nodes that accept incoming connections are far less vulnerable, since
the probability of success decreases exponentially with the number of
connections. 95% botnet control with 125 connections has 10^-6 chance
of success.
Perhaps we could add a command-line option for increasing the maximum
number of outbound connections. That way, nodes unable to accept
incoming connections can easily decrease their susceptibility to Sybil
attack.
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. =C2=A0When testing the
> list of built-in bootstrapping IP addresses I always connect fairly
> quickly, and the DNS seeding hosts seems to be working nicely, too.
I think it should be disabled by default one release after the new
address manager is released. That way, we're not changing too many
parts of the bootstrapping process at once.
As an aside, I can't help but wonder whether ISPs blocking IRC traffic
filters some botnets out of the IRC bootstrapping channels; keeping
them more "pure".
--=20
Michael
|
