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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <michael@ndrix.org>) id 1Rrumb-0007TL-Rr
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Jan 2012 17:12:45 +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 1RrumW-0008P5-0P
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Jan 2012 17:12:45 +0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A4C272079F
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 11:53:27 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
by compute3.internal (MEProxy); Mon, 30 Jan 2012 11:53:27 -0500
X-Sasl-enc: PrZ3gs1dN3c0vUzEteq2sTj30AYHTnPyvArmI3Iu1wBl 1327942407
Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com
[209.85.216.175])
by mail.messagingengine.com (Postfix) with ESMTPSA id 765A58E01A7
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 11:53:27 -0500 (EST)
Received: by qcha6 with SMTP id a6so2420609qch.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 08:53:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.78.203 with SMTP id m11mr7007696qck.86.1327942407217; Mon,
30 Jan 2012 08:53:27 -0800 (PST)
Received: by 10.229.238.147 with HTTP; Mon, 30 Jan 2012 08:53:27 -0800 (PST)
In-Reply-To: <CAPg+sBjNTS3n8Q3XzZi5GpBL6k_-4AxRKr0BkWa=-AAVgqS=2Q@mail.gmail.com>
References: <CAPg+sBjNTS3n8Q3XzZi5GpBL6k_-4AxRKr0BkWa=-AAVgqS=2Q@mail.gmail.com>
Date: Mon, 30 Jan 2012 09:53:27 -0700
Message-ID: <CAFHuXub52Lu4T0mCWoPoCrHGhCXyLpmEpSWn32_PZPjaRGL2LQ@mail.gmail.com>
From: Michael Hendricks <michael@ndrix.org>
To: Pieter Wuille <pieter.wuille@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: 1RrumW-0008P5-0P
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: Mon, 30 Jan 2012 17:12:45 -0000
On Sun, Jan 29, 2012 at 7:31 PM, Pieter Wuille <pieter.wuille@gmail.com> wr=
ote:
> wanting to move to IPv6 support in the Satoshi bitcoin client
> somewhere in the future, the way IP addresses were managed is not
> really possible anymore. Right now, basically all addresses ever seen
> are kept - both on-disk and in-memory, and sorted on last-seen time
> with some randomization. For some people this lead to multi-megabyte
> addr.dat files that took ages (well, seconds) to load.
I think this is a great change for IPv4 too. On certain machines with
slow IO, I routinely delete the address database before starting
bitcoind to improve load times.
> After some discussion with Gregory Maxwell and others on IRC, I
> decided to write a specialized address manager based on an entirely
> different principle: only keep a limited number of addresses, keep and
> index them in-memory, and only occasionally (and asynchronously) dump
> them to disk.
I've started a couple patches with a similar design, but not produced
anything I'm happy with. That work has persuaded me that this
architecture is a valuable improvement over what we have today.
> This of course leads to a weakness: attackers may try to
> poison your entire address cache with addresses they control, in order
> to perform a Sybil attack. This is especially dangerous in the context
> of IPv6, where much more possible addresses exist.
If the Bitcoin client has multiple peer discovery methods enabled
(IRC, DNS, seed nodes, etc), it might be wise to guarantee that at
least one peer is selected via each method. This requires a Sybil
attacker to control all peer discovery methods for a successful
attack.
> To protect against this, we came up with this design: keep two tables:
> one that keeps addresses we've had actual connections with, and one
> that maintains untried/new addresses. Both are separated into several
> limited-size buckets. Each tables provides a level of protection
> against sybil attacks:
> =C2=A0* Addresses in the first table are placed in one of only a few
> buckets chosen based on the address range (/16 for IPv4). This way, an
> attacker cannot have tons of active nodes in the same /16 range, and
> use those to fill the table.
> =C2=A0* Addresses in the second table are placed in one of a few buckets
> chosen based on address range the information came from, instead of
> the address itself. This way, an attacker spamming you with tons of
> "addr" messages can only still have a limited effect.
Cool design. It seems resilient to many attacks. A Sybil attack
coming from a large botnet (which controls addresses in many ranges)
can still fill all buckets in both tables, I think. As far as I can
tell, that wasn't possible with the old design.
--=20
Michael
|
