New IRC bootstrapping using random channels.

[CD-RW]

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...

Code:

channel = "#bitcoin" + random.randint(00,99)

# Joins the channel
ircsock.send("JOIN "+ channel +"\n")

# Set channel limit to 1 (clients can't join because it is full)
ircsock.send("MODE "+ channel +" :+l 1\n")

# Send a message that it has taken over the channel
# ircsock.send("PRIVMSG BadDude :I just took "+ channel +"\n)

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

[1714937640]

1714937640

[Matt Corallo]

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?

[Pieter Wuille]

I've got 00-24.

[CD-RW]

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

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

[theymos]

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

[Mike Hearn]

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

[CD-RW]

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

This would be even better!

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

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

[Mike Hearn]

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

[Matt Corallo]

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.

[CD-RW]

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

[Matt Corallo]

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.

[wumpus]

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

+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

[CD-RW]

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

+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?

[Pieter Wuille]

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.

[Mike Hearn]

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.

[Matt Corallo]

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.

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.

[Pieter Wuille]

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.

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.

[Gareth Nelson]

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

[Matt Corallo]

How about a mix of protocols?

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.

[1bitc0inplz]

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

+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

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