From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 In-Reply-To: Date: Tue, 31 Jan 2012 13:50:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0491E579-66B9-4E23-859E-90E1ECC98D66@heliacal.net> References: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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