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
155
156
157
|
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 <gmaxwell@gmail.com>) id 1Rs3uh-0004bu-1C
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 02:57:43 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=gmaxwell@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rs3uc-0004j3-Rl
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 02:57:42 +0000
Received: by vbbff1 with SMTP id ff1so2078368vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 18:57:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.91.200 with SMTP id cg8mr6978801vdb.65.1327978651788; Mon,
30 Jan 2012 18:57:31 -0800 (PST)
Received: by 10.220.151.200 with HTTP; Mon, 30 Jan 2012 18:57:31 -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:57:31 -0500
Message-ID: <CAAS2fgRPj29FSBcC_RQbufSC5tPhnZjguUQVAaWOn2VN6DZR1A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
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.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rs3uc-0004j3-Rl
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 02:57:43 -0000
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen <gavinandresen@gmail.com> w=
rote:
> 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.
S=CE=BF=E2=80=94 would we remove it or leave it deactivated as a fallback u=
sers can turn on?
I have two different thoughts about IRC depending on the answer.
I think it's important that we have more mechanisms then just DNS and
hardcoded seednodes.
This is important because the mechanisms we have are all pretty
subject to blocking. Now=E2=80=94 before you say it=E2=80=94 Bitcoin isn't =
intended to
be blocking resistant (combine it with Tor and Tor anti-censorship
tools) but by making blocking a bit harder we discourage people from
even trying, even if we're not seriously in the anti-blocking
business=E2=80=94 and it gives bitcoin users more confidence because there =
is
a bit less FUD "What if your ISP blocks it?? It uses DNS! Someone
might take away the domains! SOPA PIPI ACTA CIPA Alakazam".
Is the fact that users can addnodes / addr.txt enough of an
alternative to address this? _If so_, then removing it is a good
idea. I volunteer to maintain a multi-channel joining node for the
foreseeable future to avoid letting old clients get partitioned
(several people need to do this).
An area where I think our mechanisms are inadequate absent IRC is
announcing new nodes. I had a new listener up for over a week recently
and was basically getting no inbound until I enabled IRC. I
volunteer to do some measurement of this (e.g. bring up some nodes
with no irc and find out how long until sipa hears about them). If
DNS seeds are slow to learn about new nodes we may need to add a
simple UDP announcement feature.
In any case, I hadn't been thinking that we would completely remove
IRC=E2=80=94 I was expecting us to keep IRC around but turned off.
In particular I think it may be a little risky to turn off IRC at the
same time as deploying addrman, because if addrman has unexpected bad
behavior IRC is what may keep things going. Obviously it should be
well tested enough to feel confident, but belt-and-suspenders is the
way to go.
If we do keep in the long run I think it's important to _fix_ IRC.
Right now it has some really stupid behavior which is highly
pro-partitioning.
*/who only returns a few nodes, and because most idlers aren't
actually working (no port forward) it's usually for there to be only a
few that work. (I've never seen zero, but I've seen 1).
*Other than who we only learn about nodes when they join. But the
stable long lived nodes we need to hear about seldom rejoin. Nonuseful
windows boxes go up and down a lot.
*Nodes sit in a single channel forever. There are 100 of them.
Especially with fewer clients on line nodes may be sitting alone with
no correctly working nodes with them.
*Nodes recently seen on IRC are highly promoted in the peer selection.
So, here is an updated irc.cpp which I've been running (in various
versions) for a while:
http://people.xiph.org/~greg/irc.cpp
It does the following things:
* Only stays connected for a half hour
* If its sure its not listening it uses a random nick so people won't
try to connect
* Reconnects if it needs more connections
* If the node is actually listening (evidence by actual incoming
connections) it reconnects on its own every 1-2 hours and joins two
channels at random rather than one.
(it doesn't change peer selection=E2=80=94 It's hard to be confident of the
impact of that change. I think addrman makes it less of an issue)
I've only not submitted it as a pull request because I haven't had a
chance to test to my standards, and because I felt unsure about the
future of IRC.
I feel strongly that if we're going to keep IRC as a backup we should
fix it. If we're not going to bother then thats fine=E2=80=94 but I think w=
e
need to think carefully if we're doing enough for bootstraping (with
the points I made) without it.
Certainly getting it off by default would be a good move. The botnet
allegations are horrible.
|
