[ANN][MAX] MAXcoin - PoW, ASIC Resistance, Keccak GPU Mining

[reorder]

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.

[1714920927]

1714920927

[1714920927]

1714920927

[1714920927]

1714920927

[miningpoolhub]

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.

Thank dev.

I think you'd better roll back to before the hardfork source code and just change block time and block reward.
This kind of forking problem didn't happen at recent maxcoin hardfork. So it doesn't look like just the problem of running new version peer rate.

I saw this situation some months ago with Darkcoin.
Currently dynamic checkpoint seems like to not working properly. I don't know where this checkpoint sync source code came from but even Darkcoin is not forcing this type of sync currently. They failed hardfork issue twice and changed to soft fork their blockchain. This kind of problem happened on Bitcoin also, and it needed several weeks to fix.

It's really not an easy problem on p2p. This kind of problem is hard to simulate on testnet and makes investors disappoint as time passes. This network breaking really harms maxcoin and its confidence also.

I just recommend you to give up dynamic checkpoint sync, roll back main source code to before the hardfork and change block time and block reward. This is safe, and makes things smooth.

[limbaugh]

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

Oh that's just great, blame 1gh for your total lack of development skills. Maxcoin will never recover with this clown at the helm.

Luke has more integrity that any crypto developer I've ever met. 

How is Mr Integrity working out for you?

[miningpoolhub]

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.

[reorder]

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.

[maxcoinproject]

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.

[Spoetnik]

Cryptsy wallet still showing:  "offline while we perform system maintenance" when I try to withdraw coins.

I've never seen them take so long to update a wallet.  Is MAX not a direct BTC or LTC clone?

Anyway, I'll try again tomorrow.

Cheers!

no it's a clone of Blake Coin..
Basically the same thing as Quark minus all the other Algo's except Keccak / SHA3 left in only..
so it's very different than LTC/BTC

i did not look at the wallet source code.. Luke was saying it was a Check Point issue but that is taking his word for it i guess
no idea why it seems we're forked here ..is that all he did ? (update check points) ..weird !

i just turned on my OLD wallet after several hours again now and once again it seems to sync up fine.

edit:
this is one of the things i like about Jackpotcoin too the guy knows what he is doing and has made a far more complicated innovative coin
and the JPC dev has continued to give endless updates since it's launch months ago with out disappearing etc..
a quality dev we can count on with obvious above average skills !

and JPC is not even on Cryptsy but IS on 11 other exchanges LOL

It is a combination of factors, one of which is majority of hashrate running the old version. You have to run the new client with checkpoints disabled and block database removed so it resyncs from scratch: your current block database is beyond the point it can reorg.

WHY is the old block chain invalid by the dev adding new checkpoints on a wallet update ?

edit:
Also i seen no mention from the Max coin dev to delete our old block chains either..

edit2:
having to re-download 1.75gb's of block chain data is gay ass faggy bullshit by the way

i have wondered for quite a while does anyone have both the old and new source code to compare ?

has this been verified ?

Technical Changelog

    Increased block time to 60s
    Reduced block reward to 16 MAX
    Added automatic-checkpointing
    Fixed ‘copy transaction ID’ bug in UI
    Added dumppubkey RPC call
    Improved sign/verify UI
    Changed sign/verify to use hex encoding
    Changed makekeypair to use hex encoding

http://maxcoinnews.net/maxcoin-v0-9-2-0-release-notes/

edit:
also i don't even know what the reward was before lol

[miningpoolhub]

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.

So did you try restarting your daemon?
I tested it several times in my own pc and it stuck when it restarted.
I even wrote down well working daemon's peer list and added to addnode list but when it restart, that daemon went into trouble and no sync at all.

Tell me what happens when you restart your daemon.

[maxcoinproject]

If you're still having trouble syncing, please try the following steps:

• If you're a mining pool or exchange you can update to the latest commit via GitHub and build from there
• If you're a user, please wait for the binaries to finish building. They're on their way!
• This update contains a new checkpoint key and the "resetcheckpoint" RPC call to invalidate the broken checkpoint floating around the network
• Once you've update, run "resetcheckpoint" via the command line or debug console
• If you still cannot sync, run maxcoind/maxcoin-qt with the "-rescan" option

[miningpoolhub]

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.

[maxcoinproject]

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.

[subSTRATA]

1GH might be running 0.9.2 but if it is so then 0.9.2 is completely fucked up on multiple levels:

1. Nodes 0.9.1 successfully sync to 1GH block height (blockchain) - dozens of 0.9.1 nodes connected to my 0.9.2 node report the same height as 1GH and blockchain explorer.
2. Rate of block generation is few blocks (up to 5) per minute instead of 1 per minute on average.
3. Difficulty is not reacting fast enough or is just wrong somewhere.

There should be a complete rollback to pre-hardfork point. No blockchain is correct right now and developers should not respect anyone's work done on a wrong data. If they do it
that would mean this whole mess was (yet another) deliberate scam.

New MAX logo sucks balls, please continue using original one.

[zccopwrx]

Just worrying now about a 51% attack? Hasnt 1GH been 70-90% of the hashrate since.. forever now?

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.

[maxcoinproject]

Just worrying now about a 51% attack? Hasnt 1GH been 70-90% of the hashrate since.. forever now?

Actually they have been sub-50% for many weeks, until today. Whilst we have been concerned about the hashpower majority 1GH has previously held over the MaxCoin network there was little we could do about that other than encourage miners to diversify and be responsible. 1GH has never launched an attack on MaxCoin so we have no reason to distrust them - they're a very solid mining pool.

The binaries for the fix are available at here. We are concluding the testing with them now.

[ElBurro]

Just worrying now about a 51% attack? Hasnt 1GH been 70-90% of the hashrate since.. forever now?

 96.7% of total net at block 602640 - according to 1gh. What a mess.

[miningpoolhub]

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.

[miningpoolhub]

If you're still having trouble syncing, please try the following steps:

• If you're a mining pool or exchange you can update to the latest commit via GitHub and build from there
• If you're a user, please wait for the binaries to finish building. They're on their way!
• This update contains a new checkpoint key and the "resetcheckpoint" RPC call to invalidate the broken checkpoint floating around the network
• Once you've update, run "resetcheckpoint" via the command line or debug console
• If you still cannot sync, run maxcoind/maxcoin-qt with the "-rescan" option

I tried and it doesn't work.
Struggling with maxcoin whole day. Why aren't you reverting?

[maxcoinproject]

If you're still having trouble syncing, please try the following steps:

• If you're a mining pool or exchange you can update to the latest commit via GitHub and build from there
• If you're a user, please wait for the binaries to finish building. They're on their way!
• This update contains a new checkpoint key and the "resetcheckpoint" RPC call to invalidate the broken checkpoint floating around the network
• Once you've update, run "resetcheckpoint" via the command line or debug console
• If you still cannot sync, run maxcoind/maxcoin-qt with the "-rescan" option

I tried and it doesn't work.
Struggling with maxcoin whole day. Why aren't you reverting?

I've PM'd you. I'm testing a fix that won't require reverting.

[diskodasa]

New wallet!!!
https://github.com/Max-Coin/maxcoin/releases/tag/v0.9.2.1

[subSTRATA]

Actually checkpoint is not needed for hardfork. Hardfork don't need to be holding 51% major hash.

Not even major hashrate is needed for successful hardfork - what new nodes must do is ignore any node which does not comply to the new ruleset, it is as easy as that. Even
some coins laughed at by most people did it right (see Flappycoin, if node is not at least v3.1 it will end up ignored immidiately, you will never ever see it connect even for a split
second) but instead of just using what worked - which is what they did in the first place by cloning Bitcoin - so called developers opted for some untested techniques and stuff
that realy make no sense.