Jeff Garzik pointed out that Bitcoin-Qt no longer operates using the IRC bootstrap, and on inspection he’s right. This mainly applies to older versions of bitcoin.
Bitcoin-Qt maintains an internal list of nodes it can try to connect to when you start it up. It randomly picks IP addresses from this list and tries to connect to them until it has 8 connections. Then you are a full participant in the p2p bitcoin network.
However the first time you ever start the client, this list will be empty and so it has to populate this list. Currently it first tries an IRC bootstrap, and then falls back to a hardcoded list of nodes to populate this list if there is a problem using the IRC bootstrap.
IRC is a protocol for instant messaging over the internet. To bootstrap means to initialise a system. In this case IRC bootstrap means a way of discovering other nodes on the network the first time it starts up by using a chat protocol called IRC.
In Bitcoin-Qt and other clients which support IRC, every participant is always in an IRC chatroom termed ‘channel’. When a new client for the first time wants to discover nodes in the network so it can join the p2p network, it will connect to the server with this chatroom, then join the chatroom, list the users and connect to those users as bitcoin nodes.
Here’s the problem: IRC is for chat, not a mechanism for network discovery. As such, the rules and limitations of IRC are limitations meant for chatrooms.
At one stage in time a few months ago, the bitcoin network got far too big to have everyone in the same IRC chatroom. Whereas before every bitcoin node would announce themselves as being available in #bitcoin channel on the LFNet server, it got to the point where the IRC server was disallowing bitcoin nodes to join the chatroom because there were too many participants in the channel.
There are two fixes if you wish to keep using IRC:
- Expand the number of chatroom users.
- Split bitcoin nodes across many channels.
There are real reasons why chatrooms have a fixed limit on the number of users in a channel. Normally there is a rate limit on the number of messages you can send to an IRC channel to stop people performing a denial of service attack by flooding the channel with too many messages faster than the server can handle. Allowing unlimited numbers of users in a channels, allows people to circumvent this restriction by joining with multiple accounts and flooding the channel by rotating among their accounts and evading the rate limit protection. As bitcoin nodes in the network would have to read and interpret this information, it would also mean that traffic would flood from the IRC network to the bitcoin nodes. The IRC network would be exploited into attacking the bitcoin nodes.
The second option which was adopted was to randomly connect to a channel from #bitcoin00 through to #bitcoin99. Nodes looking to find other bitcoin nodes could then join one of these random channels and find others while being within the channel limit setting for IRC.
I don’t like this fracturing of users. It’s bad security practice to split a network which gets its security from being the sum of the whole. There are many empty channels on LFNet at any one time like #bitcoin32 at this time of writing (14:39 16 April 2012). A malicious party could join one of these channels and completely populate them with their own malicious nodes. A new bitcoin would then join one of these black channels and be totally controlled by the malicious host who can feed them fake blocks and perform a sybil attack by totally surrounding them and controlling all the information they receive.
What can be done? We already have the solution in front of us. A third option exists which is disabled by default called DNS bootstrap. If a node is unable to connect to IRC, then it will try to connect to a number of hardcoded nodes to aid in bootstrapping and ask for addresses. This security is far better.
Rather than trusting one IRC server, or one channel, we trust several nodes. It is the approach I use with libbitcoin which is used in the Electrum server, and it is perfectly fine and reliable after much testing.
Bootstrapping nodes have no limitations on the number of addresses they may store, and not only are they limited to only online bitcoin nodes but they also keep a store of offline nodes which quickly beefens up a bitcoin node doing bootstrap node discovery for the first time. It is also faster to connect to and more reliable than IRC as the IRC server has a single point of failure if it goes down.
Bootstrap nodes could even be specialised for this task by disabling all the other bitcoin functions like blockchain download and propagating transactions, instead only allowing a bitcoin node to connect and request addresses of bitcoin nodes that make up the network. This would allow their capacity to be much larger.
There is other solution which is to bundle bitcoin clients with a pre-prepared list of nodes. However from my experience and testing of generating lists of 50,000 nodes, this rarely works because the bitcoin network is in a high-rate of constant flux. Most of that list quickly becomes invalid after a few days and so it takes a long time to find a working node. I prefer bootstrap nodes over a pre-packaged list of nodes simply because of reliability. The latter would be more secure too if the bitcoin network wasn’t as flittish as it is. However right now it is the fallback for when IRC doesn’t work, when DNS bootstrap should be instead.