Quote from: maxcoinproject on September 06, 2014, 01:42:10 PM

Quote from: reorder on September 06, 2014, 01:21:41 PM

Quote from: miningpoolhub on September 06, 2014, 01:16:18 PM

Quote from: reorder on September 06, 2014, 11:40:21 AM

Quote from: maxcoinproject on September 06, 2014, 10:51:23 AM

There are clearly several major issues on the network at the moment that I will be spending the day resolving. The first is that there is still a large number of people using the old client, causing lots of invalid blocks to be mined. The second is that a checkpoint on an invalid fork is floating around the network and needs to be invalidated: please leave checkpoints turned off until a fix is released. An update solving these problems will be released as soon as I can ascertain that nothing else is wrong.

If 1gh continues to mine on their own fork it will be a sad loss to the network.

Thanks for the patience guys.

1gh is running MaxCoin version v0.9.2.0-g8c5e74e-beta (2014-09-04 17:34:31 +0100), with checkpoints disabled. If you delete blockchain db, it is the fork your client will eventually converge to.

Well you can't guarantee that 1gh's blockchain is the only one, available blockchain.

Tell me if you succeeded with current daemon restart, and sync is running properly. I think it will not sync to that blockchain again.
I'm not sure what the core problem is, but official maxcoin source have critical bug in it and cannot be recovered automatically.

Just stop pool running like miningpoolhub and dwarfpool.

The problem is a majority of hashrate still running 0.9.1 (botnet perhaps). Your node drops to safe mode seeing invalid chain having more work than the one it considers valid.

What reorder says appears to be true. I am testing the fixed wallet now and it's syncing to the 1GH chain. You can see this at http://maxcoin.co.uk:2750/chain/Maxcoin.

Try restarting your daemon. It will stuck.
Even you connect to the right peer with working peers.

I see proof-of-work error on debug.log when submitting blocks. It will be not easy for testing for you since our pool is handling GH to test on submitting block.
It can't be explained that submitting block is failed even on fork.

I even tried checkpointenforce=0, -disablesafemode but no luck.

You know that checkpoint had bug even before hardfork. Just get rid of it and revert. I don't understand why maxcoin needs checkpoint resync.