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.
I wonder if it would be possible to somehow leverage the DHT system of bitttorent to inject bitcoin peer information and have a bitcoin client query the bittorrent dht for this information. My understanding is the bittorrent DHT cannot be punched in the face by authoritarian blowhards as easily as the public DNS system can be. So you could inject peer information about a bitcoin related torrent (perhaps a torrent of the block chain at the current height?) and then the bitcoin client would get that peer information out and bam there you go right? Interesting to think about.
This post is woefully confused in several ways, and you don’t know what a Sybil attack is.
“A new bitcoin would then join one of these black channels … and perform a sybil attack by totally surrounding them”
The surrounded node will be unable to get useful work done — this is a DENIAL OF SERVICE attack, not a Sybil attack.
Because of checkpoints (even ridiculously outdated ones) the client cannot be HARMED without spending infeasibly large amounts of money on the attack. The bad data (i.e. a fake blockchain that obeys the hardwired maximum-difficulty-adjustment-rate rule) which must be fed to the client in order to run a double-spend attack on it can only be created by expending computational resources (i.e. hashpower) with a current market value well into the hundreds of thousands of dollars.
Repeat after me: bitcoind security is based on *hashpower* majority, not *IP address* majority.
Sorry, that was supposed to be a reply to the article, not to BladeMcCool’s comment.
This post is woefully outdated by several months, and does not cover current bitcoin technology.
1) DNS bootstrap is default method, in current upstream bitcoin client. It is NOT disabled, and has not been disabled for many months / several releases.
2) IRC bootstrap is disabled by default, in current upstream bitcoin client
3) Field experience has proven that hardcoded bootstrap nodes are unreliable, and are LIKELY to disappear inside of 12 months. The hardcoded bootstrap node list must be continually replaced. IP addresses change. People get bored with bitcoin. Life happens.
The hardcoded bootstrap node list is the least reliable method of bootstrapping.
Yeah you’re right now I look closer. I’ve added a header. Good to see the recommendations I make are the default now. But your third point – read my last paragraph again.
Rather than using DNS, maybe use a scheme that employs the Namecoin blockchain to store a list of current fallback node IP’s somehow? (I’m not aware the bitcoin blockchain can be used to do this but I could be wrong).
Since it secured by merged mining with the bitcoin hashing power it will be ‘self-secured’, i.e. not relying on DNS system. Hard-coded fall-back nodes is a kludgy solution, imho, in light of the immense security of the bitcoin network itself.
The decline in IRC traffic (and thus the absense of any clients on #bitcoin32) is mainly because of IRC being disabled. (I agree it wasn’t perfect before – but it has only ever been one of many bootstrappig mechanisms; the main and most important one being the addr.dat file that ships with the client). It is also a result of an apparent decline in overall useage of the mainstream bitcoin client, probably in favour of online wallets such as blockchain.info and possibly other thin clients such as electrum.
This post is woefully confused in several ways, and you don’t know what a Sybil attack is.
“A new bitcoin would then join one of these black channels … and perform a sybil attack by totally surrounding them”
The surrounded node will be unable to get useful work done — this is a DENIAL OF SERVICE attack, not a Sybil attack.
Because of checkpoints (even ridiculously outdated ones) the client cannot be HARMED without spending infeasibly large amounts of money on the attack. The bad data (i.e. a fake blockchain that obeys the hardwired maximum-difficulty-adjustment-rate rule) which must be fed to the client in order to run a double-spend attack on it can only be created by expending computational resources (i.e. hashpower) with a current market value well into the hundreds of thousands of dollars.
Repeat after me: bitcoind security is based on *hashpower* majority, not *IP address* majority.
The last checkpoint is at block 168000. Your point would be true if checkpoints continue on forever (but they don’t). If you surround a node, you can easily feed them fake blocks, especially if you are the first to populate their addr.dat with only your fake nodes.
No, not “easily” — fake blocks must have plausible proof-of-work or they will be rejected. See the ComputeMinWork() function in any recent version of satoshi-bitcoin.
So for an attacker to feed you fake blocks they must be willing to perform real proof-of-work, which makes the attack costly (because they could instead be performing REAL proof-of-work on the main chain and earning bitcoins).
Most probably everybody who ever built his own Bitcoin client shares the same ambiguous feeling regarding the dns-seeding of the bitcoin nodes. It doesn’t feel right .Together with the fact that the bitcoin client/network signals a transaction as valid after 6 confirmations it becomes a part of the software one wants to change immediately.
Therefor I’ve started recently to explore the possibility to use Telehash as an alternative to ‘node-seeding’ and ‘transaction-dissemination’ mechanisms. Telehash is by any means improving and enriching the possibilities of Kademelia for setting up distributed hashtables for other things then filesharing.
The results of these experiments show that Telehash has a lot to offer to bitcoin transactions and blockchaining: anonymity , efficiency, scalability, versatility.
…and it delivers one very important innovation: it can help to make the bitcoin-nodes, which are delivering proof-of-work services, absolutely anonymous.
Telehash looks nifty! I really want to see more experimentation with transactions/blocks/etc transmitted over alternative network protocols, diversity of implementation and network is a good thing.
… sorry for misspelling: it’s Kademlia!