The behavior a typical firewalled new users sees is that they start the software and they see 0 connected.
The system may spend hours in this state. Restarting the client repeatedly may make it get connected, but it may not receive any blocks. Eventually if the operator is patient enough and/or restart enough they will probably get synced up to the network but it may take then 24 hours.
I think this gives users an initial impression that the bitcoin technology is unreliable and dampens interest and confidence in bitcoin.
After IRC discussion it seems that the problem seems to be the result of several interacting issues:
(1) The connect() timeout behavior is unreasonable. Once the 8 slots are filled up with connections to unreachable hosts the node will just sit there idly. I think the OS will eventually give up— but only after 5 minutes or so. this is worsened by the fact that:
(2) Most nodes on IRC are unreachable. We've had a large amount of newbie growth lately and lots of nodes are up behind firewalls without port forwarding. If you grab 8 nodes from IRC it is appears fairly likely that you get all 8 non-reachable.
(3) addr.dat remembers nodes which you've never connected to (or only connected to long ago) and these non-working addresses are passed on to other nodes when you connect to them. So even when you do get a working network connection you'll likely get fed more addresses that make connect time out. (there also appears to be a DOS vulnerability here, since I could run a node that simply claims every IP is a bitcoin node)
If they addnode a working node, or forward the port then it will work too (though addnoding after an addr.dat is full of junk seems less effective). But that is a lot of non-obvious work to just get the software going.
This situation is severe enough that when I spun up eight totally new test nodes (behind a firewall), all eight were still sitting at zero connections five minutes later. I had another test node run for 20 hours and not get any blocks— though it did get connected, most likely because it ended up in an island of new nodes, so thats probably another issue.
Fortunately this isn't terrible to fix:
Issue (1) has a patch available
https://github.com/phantomcircuit/bitcoin/tree/nonblockingconnectIssue (2) can be addressed by the use of DNSSeed (which checks that hosts are reachable before including them, and could also check to make sure they weren't islanded nodes)
Issue (3) seems like a mostly straight forward fix though the security implications need to be thought through.
Additionally, enabling UPNP by default would help by getting more nodes listening, but thats not sufficient without solutions to (1) and probably (2).
But these fixes need to actually get into the software to be of any use. I don't think many long term bitcoin users are realizing the severity of this problem because they either have established nodes, public IPs, or port-forwards, and because the issue has become much worse in the last two weeks. (I didn't experience it personally due to forwarding the port, but a regular stream of people into #bitcoin asking inspired me to investigate some)
