Bitcoin Forum

Currently there are 10,000 Bitcoin clients on the IRC server, in the main channel. Since you don't need to see all clients quit/join or get a 10k client list there is now the new system called 'split channel'.
This means a client will not join #bitcoin, but it will join #bitcoinxx, where xx is a random number between 00 and 99.
It is a great idea and will cut down bandwidth usage a lot for the server and the client!

There is one (major) downside for this.

What if an attacker would make bots join #bitcoin00 till #bitcoin99, and has OP (@) in all channels? He could lock the channel with a limit of one (+l 1), set a key (+k ywebnxs), or he could even ban everyone (+b *!*@*).

This would not work if all the channels would already have people in them, since OP would only be given once to the first one joining.
At the moment there are only 6 clients in the #bitcoinxx channels, so it's vulnerable and could be exploited any moment.

Possible fix: get some sort of IRC module/script to take control over these channels before an attacker does. This could either by joining the channel and let it de-OP itself, or never give OP in a #bitcoinxx channel.


Not fully working but to give you an idea, here is a bit of python script...


I see you guys found a quick fix: Join channels manually and de-OP yourself there.

Ok, so easy fix...people who won't break the chans join now until they have a ton of nodes in them, Ive got 75-99, someone want to grab the rest?

I've got 00-24.

Great! I got 25-49, and 50-74.

I would ask you guys to de-OP yourself, and not become OP again. :)

Maybe laszlo can set it up so that no one can be an op in those channels.

It'll take a long time for people to move across to the new channels. We might as well just switch to DNS instead.

This would be even better!

IRC will be fine, people just need to update faster. Need something like update notice in about window?

IRC isn't a sustainable discovery protocol anyway. It has lots of problems beyond startup time.

Very true.  DNSSeed is a much more appealing option, and there are some cool potentials there for faster startup as well.

How would one publish his availably to a DNS record then?

My idea: People still log into the IRC channel as now (so many in the community are so against centralization that they might wish to keep using this for bootstrapping connections, and they have every right to that) and then the DNS Seeds use the list from IRC to check which IPs accept incoming connections.  They keep a list and serve DNS records from that list.  That way DNS Seeds always have the most up-to-date list of nodes accepting incoming connections to give out to new clients.

+1

I think the final straw is that it sets of botnet detectors for some ISPs. The last thing we want is for bitcoin to be classified as botnet :)

Botnets don't have be malicious, think of distributed computing?

Matt, what are these DNSSeeds your talking about? Can these be implemented by resolving a DNS record?

See the -dnsseed option. It uses DNS records that resolve to many IP addresses as seed.

IRC is also centralized, it just puts control of the network into the hands of the LFnet admins instead of community members who are incentivized to see Bitcoin succeed.

With DNS discovery a few well known domain names resolve to a set of listening IP addresses. The set might be fixed or it might be recalculated every so often based on addr broadcasts. No matter what happens after you bootstrap your node will have its own address list that it will use to get back onto the network, you only need DNS the first time you run it or if all the addresses you heard about previously have gone away.

Yep, dont remind the community at large ;).  Also, LFnet is just lazslo, though I think most people dont know that which is partially why people don't seem to care about the centralization of the IRC bootstrapping stuff.

Exactly, DNS seeding differs from IRC seeding, since the addresses in it can be edited by the maintainer. But the P2P protocol exchanges IP addresses internally as well, so you could say that the node(s) whose address the DNS seed resolves to plays the role of what used to be the IRC server.

Maybe we could make a specialized/simplified P2P node that only tracks accessible addresses (not necessarily keeping addresses open), instances of which could populate the DNS seeds.

How about a mix of protocols?
IRC - across different servers AND channels
HTTP - REST API to publish your own IP and get other nodes
DNS - do A lookups, dynamic DNS updates
Bittorrent - create a torrent that doesn't actually transfer files but serves to hookup bitcoin peers and also helps confuse people with the name ;)

Why make it so complicated?  We already have 3 methods to bootstrap, and if we just do a bit of tweaking on the DNS seed servers, it should solve all the slow-to-bootstrap problems.

True. My ISP just blocked something yesterday, no connections  :(

I setup Tor last night just so I could proxy Bitcoin through it so it could connect.

Bitcoin needs to NOT use IRC, IMHO. It's too prone to being taken down by ISPs. I don't know what to tell you guys, but I do know that it's unfortunate that my ISP did what they did.

On the bright side, I found out about the wonders of Tor yesterday and am proudly running a relay  :D

What is it about IRC that makes it look like a botnet? I happily run an IRCD and an IRC client without issue, so what's the criteria for being botnet-like?

From what I understand, it's not so much the ports and what not, but the type of transmissions and their frequency. Apparently some (all?) botnets use IRC for communications, so the ISPs have gotten to where they look for frequent and seemingly autonomous transmissions across IRC.

At least that is my understand.

Hmm, so the -dnsseed is already implemented in 0.3.12-beta and could be fully utilized any moment?
I say go, then.

Just so everyone understands..

* LFnet IRC network is primarily used for bitcoin - a few others and I maintain it and we're all bitcoin users. 

* I am a regular bitcoin contributor.  I'm also the guy that bought the 10,000 bitcoin pizza in case anyone is wondering.  I'm a moderator on this forum, I maintain the Mac OS build and I wrote the original GPU miner (http://heliacal.net/~solar/bitcoin/opencl-v2-svn-95-2010-06-30.patch (http://heliacal.net/~solar/bitcoin/opencl-v2-svn-95-2010-06-30.patch))  - I hope that's enough credentials to prove to anyone that I'm not some BOFH IRC admin :)

* We will make sure the #bitcoinXX channels are not 'taken over' or anything like that.

* The IRC servers have been configured to limit the number of records returned when a client joins #bitcoin and issues a WHO request.  This greatly reduced the bandwidth and memory requirements.

* We use and monitor IRC and will keep an eye on the #bitcoinXX channels.  The channel modes will be locked to a reasonable normal setting like #bitcoin is today.

I would like to add an option/preference to disable IRC in the client.  It should be on by default, since that's the whole point, to bootstrap new users, but then the user should be able to switch it off.  There will still be plenty of people who leave it on to provide booting to others, but not everyone needs to do that; especially if you don't have the inbound port open.

I also think that alternative bootstrap methods are a good idea, but it should be possible to switch it all off once you're connected to the network.

Thanks,
Laszlo

-noirc...done

That already pretty much happens, bitcoin prefers nodes it has previously connected to, so as long as it has made a decent number of connections in the past it shouldn't bother with nodes from bootstrap sources.  Plus keep in mind bootstrap sources are just lists of IPs, which is really no different from what you get via peer exchange. 

Couldn't you in theory hijack almost the entire network?
I'm not claiming that you would of course, but i'm wary of that ability being available to any one entity - what if, for example, someone sniffed your connection and got /oper access?

IRC could only be used to "hijack" totally new users, though maybe IRC could break things by returning millions of bogus addresses and filling up addr.dat. Does Bitcoin defend against this?

No, it wouldn't make much difference if the IRC network was compromised.

It is just used to get a list of hostnames to try to connect to, but you only need to connect to one real node in order to be able to receive the majority block chain.  It is just one of many methods used to find other nodes - the address messages broadcast on the bitcoin network are the primary means, and once you've been connected to the network the client keeps a local cache of the addresses it has seen.  The ones it sees on IRC are just added to the list.

It would be simple - just add a bunch of peers you control and use them to poison the network - you could even be evil by sending your poison peers only to certain users to avoid everyone else noticing. Send one user 30 poison peers and they see 30 connections and think everything is normal.

You'd still be able to hijack new users

That would be true of any bootstrapping mechanism you can think of. At least with IRC it's somewhat transparent in that people can log in and see what's going on.. I don't really see any way around this though..

Also, users would probably notice that they weren't on the 'real' bitcoin network since they wouldn't be receiving any payments made to them or be able to send payments and also if they ever connect to a single real node by any of the bootstrapping mechanisms then they'd 'break out' of the illusion.

Infact, there's really very little motivation to 'hijack' a new user.. all you can really do is prevent them from communicating with other bitcoin users.. you can't steal their money or intercept their transactions.. all you could do it stop them from connecting to the network.. which they would probably notice and be able to work around. I guess you could force them to work on your block chain, but since mining is now disabled in the main client anyway that is no-longer true either.

Connecting to a real node by what other mechanism?
This is why multiple mechanisms are a good thing :)

what about the proposal to use bittorrent trackers to find other peers?

see http://forum.bitcoin.org/index.php?topic=84.msg119872#msg119872

clients can also specify the port they listen on

Thanks laszlo, I didn't realize LFnet was so customized for Bitcoin.

Hmm. Needs more +m on #bitcoinXX channel, also do 'auto +m' on #bitcoinTEST. Not sure if it is possible but auto de-OP on #bitcoinXX join would also be nice.

// CD-RW

Bittorrent trackers require a DNS lookup... at which point you might as well just use -dnsseed


IRC is just for bootstrapping.  Once you get at least one valid node, you connect and exchange peer addresses.  The bitcoin peer exchange includes listen port.

Yeah, DNSSeed will work fine I guess.

DNS is a step forward in speed but also a step back in functionality.
Encoded in the IRC nicks is the port the peer is listening on. The DNS peer lookup has no way to do that the moment.
This means DNS discovery can only use the standard port which makes blocking peer bootstrapping much easier.
Not a big issue right now but it does need to be addressed at some point.

DNS does not completely replace IRC, as its database can only be updated by the maintainer, not by everyone.

However, nodes also pass known addresses (including port, even with IPv6 support) to eachother. So DNS bootstrapping is just bootstrapping, finding *some* node, that knows other accessible nodes.

I haven't been having very good luck with the random IRC channels.  Each of the random channels joined didn't have enough other clients attached.  Eventually, I just modified bitcoind to connect to good old #bitcoin instead, and now everything is peachy.  Perhaps the client should join multiple channels until enough folks have upgraded to the random channel-using clients?

It will be fine once the build is actually released and people start using it.. right now it's only the early adopters who are mostly already bootstrapped.

You could ask for TXT records which store addresses in the same format that are used for IRC nicknames.

There's not much difference between these two, as a channel operator can ban/filter addresses and an IRCop can alter the server to return basically anything. For both you need to trust the maintainer not to tamper with the service.

If you want the clients to dynamically add their addresses to the bootstrapping service, you can do this with DNS, too. E.g. set up a DNS server that accepts DNS UPDATE (RFC2136) to add new records (obviously deny delete attempts and purge outdated entries from time to time). Or set up a tiny UDP update service additionally to DNS where clients can submit their address to the database.

Here's my proposal for how a better DNS bootstrapping mechanism could work.

Each client could resolve a special dns name such as

u5MGeZm2ktRwMNV.bootstrap.ve

where u5MGeZm2ktRwMNV is the same as the nickname used on IRC and encodes the host/port of the querying client.

The DNS server in response to this query would reply with a list of some number of verified bootstrap nodes. Rather than returning a simple DNS A record, the DNS server could reply with an SRV record specifying the port number as well as the address.

The server would then add u5MGeZm2ktRwMNV to a queue of nodes to be verified and subsequently it would appear as a reply to someone else's request. Perhaps if I have time I'll hack up an implementation of this.

Wouldn't all this create partitions of the network?

If I bootstrap and randomize into #bitcoin00, the peers there will only know about themselves, no?

Not if 10k clients try to get in 100 channels.

My university ISP banned me from their network because of the IRC connections. I apparently connected to an IP on their blocklist on port 6667 and they assumed my pc was part of a botnet that got directions from that IP.

I now have blocked all incoming and outgoing traffic on port 6667 on my pc but I am not sure if bitcoin is working anymore. Is there a solution to this problem? I cant imagine I am the only one with this problem. It also prevent me from running the client without worrying all the time about getting my connection taken away.

Start bitcoin with: bitcoin -noirc -dnsseed

This will disable IRC seeding, and use the new DNS seeding method.

Thanks. Where do I enter those commands? The pat "C:\Program Files (x86)\Bitcoin\bitcoin.exe -noirc -dnsseed" didnt work.

the quotes has to stop after .exe