Bitcoin Forum

So I do realize what irc is used for, but could someone shed some light on the particular network, who is behind it and why is it the one being used?
All I found from google was pretty much that the domain is registered by "s gear" of lilo free network. But even the domain lilofree.net has disappeared.  :-\

Bitcoin doesn't use IRC.

https://en.bitcoin.it/wiki/Network#IRC
So is the wiki obsolete? It says that it's no longer used by default but not that it isn't used at all.
Edit: also checked the channels #bitcoin00 and #bitcoin01 with my irc-client and they are active  ::)

Antiquated nodes running years old software, a good number of which likely do not work at all at this point.

IRC was removed completely in 0.8.2.

https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#IRC_Addresses

P.S.  My pre-0.4 node is still running strong.

The last of code was removed then, but it had been disabled since 0.6.0.

What height is your 0.4 node at?  Straggling 0.7 nodes got stuck again last week.

Can someone tell me how exactly our nodes find each other since irc was removed? We don't get added to dns do we?

278114 which is current as I'm writing.  Interestingly, this node has never been stuck like that.  About a month after the great forking, I cranked up the locks and objects in DB_CONFIG as a precaution, but I have no idea why it didn't get stuck in the first place.

I also have a 0.7.1 node that got stuck for the first time last week.  Fortunately, it exists for the sole purpose of maintaining a set of old school 2GB block and index files for distribution, so it was easy enough to back it out to the last snapshot.  I have vague plans to replace that node with a script to repack blocks from the new small block files (I don't have much use for the old indexes any more), but unless it starts crashing on a regular basis, I probably won't get around to it any time soon.


Read the link I posted.

The failure was non-deterministic, it depends on where records are laid out relative to BDB pages. I would have been surprised if you hadn't at least failed by now, but the increased locks explains it. :)

There are seed nodes that are built into the client and when you connect to any of them, you will receive addr (https://en.bitcoin.it/wiki/Protocol_specification#addr) messages pointing to other nodes.
You can also ask a peer for its list of known peers, using getaddr (https://en.bitcoin.it/wiki/Protocol_specification#getaddr) message.

Unfortunately there is no protection from receiving a fake addresses via the addr message, but it doesn't seem to be a big issue.
Except maybe for the fact that it is supposedly the reason why the official client isn't willing to connect to ports other than 8332.

Okay, that's cleared. But what still bugs me is whose irc servers were used and on what basis. Such centralization must have had clear reasons and audits? So if anyone versatile in bitcoin dev-history can clear that I'd be even more wiser. And kind thanks to all who replied above. :)

Bitcoin originally used freenode, the #bitcoin channel actually, it got kicked off. I don't know the story of how lfnet was picked, but a lot of other networks wouldn't have welcomed the traffic.

The IRC was only used for node introductions, and nodes still had the static seednode list. Bitcoin is ~generally~ designed to be secure against network attackers, so people didn't consider it as critical as you might be. Obviously it wasn't great (esp if you consider privacy) and worked pretty poorly too, which is why its not used anymore.

When Bitcoin was kicked off of Freenode, laszlo (https://bitcointalk.org/index.php?action=profile;u=143) allowed us to use LFnet, which is run by him and his associates. It was actually good that Freenode kicked us off: it turns out that IRC is not very good for bootstrapping, and changes to the LFnet server were necessary to prevent nodes from being overwhelmed.

The changes eventually had some deleterious effects too. They limited it so that /who would only return 100 nodes (or something like that), but it was just a constant 100 based on their IRCD's hashtable (or something like that) the end result is eventually the those slots all ended up unresponsive either because they were non-listening/natted nodes or because they were overloaded.  This didn't completely break it since nodes still learned from join messages, but those came in far slower.

Thanks! This clears it. :)