I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow. On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans. And when no new blocks are in, the wallet drops to 1-2% CPU.
This is great news Tranz thank you for your hard work. I will test once you put it up.
I had a question about syncing and P2P connections... is there something in the base QT that limits connection speeds? It seems like all these old coins sync really slow no matter what... but all of these newer Java based swing wallets sync the chain like a damn torrent! Or is it just bandwidth from the peers? Or is this just a result of the bulk from 20 second block target?
Examples:
HBN (QT) gets 14 or so connections and still takes 3 to 5 hours or more to sync 2 days of blocks.
ZEN (JAVA) gets 7 to 10 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.
HUSH (JAVA) gets 5 to 8 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.
Just curious if you had encountered anything pointing to QT limitations on this.
Partiality due to fact that HBN does 5 to 6 times more blocks per day. There are things that can be done, including doing a headers first and then sync. That is in the works for sure.
Making a Java client sounds great. But it seems I am alone here and no one else is willing to step up and help with code. BTC has 100s of coders, PeerCoin, NVC, LTC have 50 to 10. Even HYP has 4 or 5. So far for a community coin, I have done 99.8% of the code work. I would love to mess around with Java but based on the current work load, its about a 2020 goal.
put i download the blockgain ... i think is a little faster ... 2-3 Blocks per seconds. The CPU ist on 30-35% (old Intel Core i5-3320M). 
I like to test the new version
