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
|
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 <gmaxwell@gmail.com>) id 1Rs7xp-0005F8-Sf
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 07:17:16 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=gmaxwell@gmail.com;
helo=mail-vx0-f175.google.com;
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rs7xp-0001Ok-2I
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 07:17:13 +0000
Received: by vcdn13 with SMTP id n13so168842vcd.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 23:17:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.148.201 with SMTP id q9mr11211216vcv.33.1327994227545;
Mon, 30 Jan 2012 23:17:07 -0800 (PST)
Received: by 10.220.151.200 with HTTP; Mon, 30 Jan 2012 23:17:07 -0800 (PST)
In-Reply-To: <CAFHuXuZ78y3nHfuKBgjO1j+bNsdnbngDee_Xii4xGhUshJqtZQ@mail.gmail.com>
References: <CAPg+sBjNTS3n8Q3XzZi5GpBL6k_-4AxRKr0BkWa=-AAVgqS=2Q@mail.gmail.com>
<CAFHuXub52Lu4T0mCWoPoCrHGhCXyLpmEpSWn32_PZPjaRGL2LQ@mail.gmail.com>
<CABsx9T0avsrL3134WaA3boG-cdx2NcgEH1mQG7Cef78ZV5UNkw@mail.gmail.com>
<CAFHuXuZ78y3nHfuKBgjO1j+bNsdnbngDee_Xii4xGhUshJqtZQ@mail.gmail.com>
Date: Tue, 31 Jan 2012 02:17:07 -0500
Message-ID: <CAAS2fgSAkCOg=E+JTuX5tSyrfCh7ZPLprNyqr6hRndK2YfMcug@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Michael Hendricks <michael@ndrix.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.2 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rs7xp-0001Ok-2I
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 07:17:16 -0000
On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks <michael@ndrix.org> wro=
te:
> address manager point to the attacker. =C2=A0If a client has 8 connection=
s
> to the network, a Sybil attack would succeed 1.7% of the time.
Meh, careful not to mixup addrman created issues with preexisting ones
simply related to the number of connections vs the number of nodes.
Even absent addressman someone who can spin up a large multiple of the
current nodes as tcp forwarders to a system they control can capture
all of a nodes outbound connections.
Increasing the number of outbound connections is a very bad solution
to this problem: It invites a tragedy of the commons: you get the
"best" security by setting your number as high as it will let you. Who
doesn't want security? Meanwhile we've come pretty close to running
out of open listening ports already in the past.
There is a much more scalable improvement for those concerned about
the sybil attack (I say those concerned because a sybil attack is not
that fatal in bitcoin=E2=80=94 checkpoints prevent a total fantasy chain, i=
t's
mostly but not entirely a DOS risk)...
The solution is to addnode a couple of (ideally) trusted nodes, or
failing the availability of trusted nodes, a few that you think are
unlikely to be mutually cooperating against you.
A single connection to the 'good' network kills isolation attacks
dead, so a couple carefully selected outbound connections its a more
secure remedy and one which doesn't explode the network.
|
