Here are the nodes I am connected to, HTH:

All good, coin launched - dev solomining it. That's how enforcing the no-pool policy works obviously 
Eventually he brings the meaning of "solomining" to a completely new level.

I am just kidding, I bet dev has perfectly good reasons for not launching yet and he will tell us very soon why he is behind schedule...

As said in PM to kevin1234a I would like my bounty to be distributed among the other 3 persons who I think have contributed most.
Thanks to those who donated to the bounty pool, I personally appreciate the thinking behind a lot and that's enough gratification for me.

If I were dev, I would make sure muddafudda keeps tuned to this thread, the best way could be to convince him to run a staking wallet by throwing some EOC toward him...  

Good point regarding seed node, however AFAIK somebody mining away at current difficulty could block (networkwise) the seed node until he has a very long chain and then come back online and win the race for longest chain.
So seed node should be updated as fast as possible now that the fix and version bump is out. Right now I only see old nodes.
Stupid me, because I am further than the seed node, I will see now nodes on new version until their blockchain is above my height. Will redownload from seed node now and see how that goes.

{
    "version" : "nvc-v1.1.2.build-g32a928e-bdb-gcc",
    "protocolversion" : 70019,
    "walletversion" : 60000,
    "balance" : x,
    "unspendable" : 0.00000000,
    "newmint" : 9.00000000,
    "stake" : 0.00000000,
    "blocks" : 20991,
    "timeoffset" : 0,
    "moneysupply" : 1258153.89093600,
    "connections" : 1,
    "proxy" : "",
    "ip" : "x.x.x.x",
    "difficulty" : {
        "proof-of-work" : 0.00025390,
        "proof-of-stake" : 0.03124954
    },
    "testnet" : false,
    "keypoololdest" : 1434032778,
    "keypoolsize" : 101,
    "paytxfee" : 0.00010000,
    "mininput" : 0.00010000,
    "errors" : ""
}

I wonder though what happens when more nodes come online regarding longest chain. I'll keep my miners idling before more nodes are online and have agreed for a chain.

@kevin1234a: Ty for your appreciation, glad I could help. I do not need any bounty, I was just curious and am still learning the ins and outs of blockchain tech.

That said, I believe just getting the chain to move is ev. not sufficient, I suspect since everybody mined a few blocks on his own chain, we are now all on a different fork. The one mining away the most of these cheap blocks will probably win the race for longest chain (Fork-Fest anyone?). 

Also regarding muddafudda's fix: As I suspect the problem arose because a block with invalid time (in the future) was accepted by the chain and resulted in a negative target spacing I could imagine it would be better to trigger the fix not from time but from a block number.
And I would also like to ask the experts around if it wouldn't make sense to bump the clients version number if that hasn't been done already? 

Hopefully somebody with more insight could comment on my above points.

Happy to see some movement again with EOC, I like the coins specs.

First line from muddafudda's proposed change is missing in the commit and int64 needs to be int64_t, then it should compile.

Please post source to github.

The fix muddafudda generously offered seems to work from my test.
Half of it made it already into github, but since its only part of the fix the github code doesn't build...

Much appreciated muddafudda, can confirm your proposed fix seems to work:

{  
    "version" : "nvc-v1.1.1.build-g32a928e-bdb-gcc",
    "protocolversion" : 70018,
    "walletversion" : 60000,
    "balance" : X,
    "unspendable" : 0.00000000,
    "newmint" : 9.00000000,
    "stake" : 0.00000000,
    "blocks" : 20991,
    "timeoffset" : 0,
    "moneysupply" : 1258153.89093600,
    "connections" : 0,
    "proxy" : "",
    "ip" : "x.x.x.x",
    "difficulty" : {
        "proof-of-work" : 0.00025390,
        "proof-of-stake" : 0.03124954
    },
    "testnet" : false,
    "keypoololdest" : 1434032778,
    "keypoolsize" : 101,
    "paytxfee" : 0.00010000,
    "mininput" : 0.00010000,
    "errors" : ""
}

Thank you, I have cast my vote.

There is quite some discussions going on if c-cex is a trustworthy exchange in different threads here, https://bitcointalk.org/index.php?topic=1127722.20 to just quote one. I don't know if having c-cex as only exchange is good idea at the moment.

Thanks for explaining. Basically I can change the Poloniex account data, but not the API keys if I get that right.
I will rather go for a new license then, no lack of trust to you, but I'd feel better with it.

I am interested. I am unsure however about how transferring works. Will I be able to get back to the author of CAT and have my Poloniex API Keys added/exchanged with yours?
Excuse my ignorance if this sounds stupid.

That's simply because there is no hash of the next block yet, it's the one being mined on. Looks the same when you query any coind on the current/next block. So in my understanding it would the hash of 20988 which we are all so desperately expecting 

Check this thread for something that sounds very close to what we see here. When I output bnTarget I get a negative value which then again rejects the block due to the check in main.cpp line 1162.
HTH

IMHO it is line 1162 in main.cpp that rejects new found (POW) blocks. Question is which of the two conditions triggers the error/reject.

Not sure about that strange node, but AFAICS the problem occures before the block even could be broadcasted to other nodes.

Maybe I am wrong, but the chain is not moving exactly because no blocks are accepted.

I tried to mine a block to see what happens in debug.log when it rejects it and the last lines I get are:

does that ring any bells for anybody?

Tried -salvagewallet, deleted blockchain and resynced - no joy.
After wasting a night worth of hash, I think I'm out.