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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <solar@heliacal.net>) id 1RsE6L-0006tw-K7
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 13:50:25 +0000
X-ACL-Warn:
Received: from pelican.heliacal.net ([173.246.103.92] helo=pelican)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RsE6H-0007ib-DF for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 13:50:25 +0000
Received: from laszlo.jax.imobile3.com (laszlo.jax.imobile3.com
[199.189.207.150])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by pelican (Postfix) with ESMTPSA id 0875418E67
for <bitcoin-development@lists.sourceforge.net>;
Tue, 31 Jan 2012 13:50:14 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: solar <solar@heliacal.net>
In-Reply-To: <CAAS2fgRPj29FSBcC_RQbufSC5tPhnZjguUQVAaWOn2VN6DZR1A@mail.gmail.com>
Date: Tue, 31 Jan 2012 13:50:13 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0491E579-66B9-4E23-859E-90E1ECC98D66@heliacal.net>
References: <CAPg+sBjNTS3n8Q3XzZi5GpBL6k_-4AxRKr0BkWa=-AAVgqS=2Q@mail.gmail.com>
<CAFHuXub52Lu4T0mCWoPoCrHGhCXyLpmEpSWn32_PZPjaRGL2LQ@mail.gmail.com>
<CABsx9T0avsrL3134WaA3boG-cdx2NcgEH1mQG7Cef78ZV5UNkw@mail.gmail.com>
<CAAS2fgRPj29FSBcC_RQbufSC5tPhnZjguUQVAaWOn2VN6DZR1A@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
X-Mailer: Apple Mail (2.1251.1)
X-Helo-Check: bad, Not FQDN (pelican)
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
0.5 VA_HELO_CHECK Host Used Invalid or Forged HELO/EHLO
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
X-Headers-End: 1RsE6H-0007ib-DF
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 13:50:25 -0000
We split IRC among all those channels to handle the load when there were =
60k clients.. the ideal thing would be some kind of dynamic sizing, and =
this applies to the number of outbound connections and transaction =
relaying logic too.. the same values that work for 1k clients don't work =
as well for 50k. It is difficult to get this kind of thing tuned =
correctly, especially with the added complexity of potentially malicious =
nodes.
I think the observed isolation problems, with or without IRC, are simply =
due to there not being many bitcoin nodes leaving/joining the network. =
The ones that are stable are happy with their 8 connections or whatever =
they're set to, and they're just relaying. There are only about 5k =
clients on IRC now.. it would probably work to go back to the single =
channel model as (at least from the IRC point of view) the usage is =
declining not growing. Maybe people are just turning off IRC though. =
IRC works well with many channels having a few clients each, not with =
one channel having many clients. We considered probing bitcoin clients =
to see if they're listening and favoring those clients in the WHO =
response, kind of like the DNS booters, but nobody got around to doing =
it.
Still, I think it's good to have a bunch of different ways to bootstrap =
in case one or the other is broken/poisoned.
Laszlo
On Jan 31, 2012, at 2:57 AM, Gregory Maxwell wrote:
> On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen =
<gavinandresen@gmail.com> wrote:
>> 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. When 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.
>=20
> S=CE=BF=E2=80=94 would we remove it or leave it deactivated as a =
fallback users can turn on?
>=20
> I have two different thoughts about IRC depending on the answer.
>=20
> I think it's important that we have more mechanisms then just DNS and
> hardcoded seednodes.
>=20
> 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".
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> 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.
>=20
> */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.
>=20
> 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
>=20
> 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)
>=20
> 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.
>=20
> 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 we
> need to think carefully if we're doing enough for bootstraping (with
> the points I made) without it.
>=20
> Certainly getting it off by default would be a good move. The botnet
> allegations are horrible.
>=20
> =
--------------------------------------------------------------------------=
----
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft =
developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, =
MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
