Great thanks to you, I want to buy the bad blocks from you and I really appreciate your great help.
I didn't mine any 'bad' blocks; there was only one which was on the end of the chain.
You're welcome
, it wasn't a huge deal though, and I didn't actually figure out the problem, just work around it.
If you'd like to send me some CMC you can here: C72cU8HH6ryHSScDqMymtYYxu5kEWjN9bx
Great, can you share how did you patch the chain? How the bad block could be attached to the chain?
I believe he just updated the code as outlined above and started mining using a version based on that code, no?
This is correct. The patch itself was:
if (GetHash() == uint256("0x000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205"))
return error("CheckBlock() : hash == 000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205");
Basically it would just fail if you tried to add block 0x000000082f31f... to the main chain, allowing me to mine from the previous block and create an alternate chain which took precedence when it became longer. Then the rest of the network took over and there were like 200 blocks in 2 minutes (the difficulty was low because it recalcs for every block).
JDDev and cosmoscoin, not sure if either or both of you are developing this, but your block target and retarget time are low enough that you might get problems. I'm not certain that is what allowed the 7886 block; the PoS aspect might have had quite a bit to do with it. In any case, there's evidently a bug that needs to be worked out.
The scheme of CMC is retarget every block, as you see the block target and retarget time is too low, I don't know how to figure this out.
It seems that NVC, Bitgem and bottlecaps don't have this problem, so I really don't know why.
