Quote from: maxcoinproject on September 06, 2014, 02:14:18 PM

Quote from: miningpoolhub on September 06, 2014, 02:07:22 PM

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.

What proof of work error are you getting? Are you still trying to create blocks with a coinbase of 48?

We need checkpointing due to the increased risk of 51% attacks in the event that our hashrate drops following a decrease in reward.

No. from coinbase 16.
It made some blocks after hardfork. http://maxcoin.miningpoolhub.com/index.php?page=statistics&action=blocks
"proof of work" error from the latest version about 12 hours before.

When the pool stuck at around 600067, 1gh, dwarfpool was stopped at that time too.
They would know this error too.

I then cloned git for the latest checkpoint you added, tried several times. It was saying that about "Safe mode" so I added -disablesafemode too at startup.
I checked the debug.log at that time and found that many submitting blocks were rejected by proof of work then.

Of course, maxcoind checkpointenforce was typed every time when I restart maxcoind.

I tried many parameter options, tested. it only succeeded syncing for typing -reindex (which will explore, check blockchain from scratch).
But when I restart that maxcoind, it stuck again.
I even tried it again with well working daemon's peer list.
I wrote down peer IP and added to addnode list for next start up.

Connection established successfully to that IPs but stuck again.

Maybe "enforcecheckpoint" parameter needs to be set to "false" by command line before the maxcoind parses previous checkpoints. I don't know inner problem but I'm sure there's big bug.

Actually checkpoint is not needed for hardfork. Hardfork don't need to be holding 51% major hash.
Wrong peers don't even affect new block chain.
Peers validates reward each other and it will "disconnect" when other peer is submitting wrong reward several times. Other coins work like that, and I'm sure maxcoin already has that feature. I can see "banscore" is available in "maxcoind getpeerinfo".

They just disconnects each other and piles up their own blockchain separately.
Dev don't need to worry 51% hash for hardfork, just choose the right blockchain for official maxcoin and that blockchain will win because dev confirmed it as official.

Don't worry and just revert to pre-hardfork.