Globalcoin still uses IRC to communicate nodes. Make sure you don't have IRC being blocked for globalcoin-qt.exe on your personal computer...I did on my personal wallet computer
Good point, but really, that should only be necessary to help find initial peers. Normally, one brand new client connecting to a single peer (found via DNS seed, addnode, IRC etc) should result in all known peers being forwarded to that client. That assumes the code isn't buggy, of course...
I set up a client, the known broken 1.5.4.1a version on another machine and put your addnodes in excluding the 216.177.81.87. It started and found three new peers that the another one was not seeing, kinda does point to a code issue with peers. It's like it has decided 216.177.81.87 is the right chain (if it's allowed to see it) and is ignoring other peers. Perhaps it is right. Perhaps the chain that 216.177.81.87 and Crtypoia are on the winning chain. Kinda screwed up this situation is.
Yeah, at this point I'm not really sure how this can be fixed. I presume the fork differences are simply too great for the clients to figure it out themselves. This is not a minor squabble over who won the past couple of blocks; there's over 80,000 blocks discrepancy between the two chains. Even if new code is released with hardened checkpoints, there's going to be a lot of mining work lost, and potentially, double spends, which will affect the exchanges.
FWIW, I had previously blocked 216.177.81.87 and a couple of other nodes to stop my client getting stuck in the reorganise loop. Did it via firewall; I don't think there is any way to manually ban peers with the client config. Now that the work value has exceeded that of the "other" chain I've allowed them to connect again. There's still a lot of redundant, wasteful block fetching - most coin clients seem to do this when there's a fork - but no more endless reorganise loops.
Not really sure where we go from here.