Just now I changed it to :
listen=0
noirc=1
connect=193.68.21.19
And I still get:
diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Aborted
Though may I ask why you want me to set all that? It effectively makes me a non-participator in the diamond network giving all network control to 193.68.21.19.
You are getting the assertion error where the index.dat file gets corrupted due to a flood of orphans. Other nodes you are connected to are feeding you crap.
Obviously you also need to replace the blockchain with the one provided in the OP. Then start the wallet. The index file is corrupted so making those changes to the .conf is useless if you don't replace the blockchain files first. Basically delete all files except your wallet.dat and the diamond.conf files and replace with the one in the OP.
Using connect=IP and listen=0 makes you indeed a "leecher" if I may say so but this is temporary. You can then revert and change to addnode=ip and listen=1 later on. This is TEMPORARY.
The index corruption issue is not something specific to Diamond. A lot more coins have the same problem and to this date there has been no fixes.
It's happened to a lot more coins? Can you link to a couple so that I can confirm that this won't happen again in the future?
I have a copy of the block chain that generates this error if somebody wants to look at it.
We all have copy of such blockchains..
This issue has been discussed a *lot* in this very thread. But, I will repeat it one more time.
There is a bug in the processing of Diamond and other coins that share the same code base. Someone apparently knows how to trigger the bug. We don't know yet the solution, but are working to find it. Many other coins have already discovered this situation and provided instructions to "fix" it, that more or less revolve around "create new block index". Obviously, as Diamond sees this more recently, it is a sure indicator we are targeted more than other coins.
The damage consists of a 'all zero' record in the block index database. The block chain verification code decides this is yet another genesis block, and triggers this assert. We could in theory work around this by ignoring that record, but it is uncertain what other damage there might be, So it is safer to just rebuild the block index database. The other databases the wallet supports (the block database, the wallet, peers database etc) do not suffer from corruption. If the cause is not found soon, we will eventually implement this "fix" ... Other coin's experience indicate this is happening irrespective of whether they use the db or leveldb database backends, so it is not a database locking issue or such -- we are fed garbage from the network.
The "fast index" code has helped reduce the occurrence of this situation great deal, but .. seeing it more recently is yet another indicator someone is trying to bring us down.
In order to rebuild the block index (and get rid of the corruption), you have these options, in descending order of "trust", but also in descending order of the downtime required:
1. You can junk the block chain (blk0001.dat, blkindex.dat, database/* files) and re-download the block chain from scratch. It is *advisable* to connect to one, and one peer only during this process, as to not end up in a fork or mess. Not necessarily 193.68.21.19, any node can do: just use noirc=1, listen=0, connect=node_address. It will stop at block 386226. You need to stop and start the wallet for it to continue past that. (we will remove that requirement at a later date) Takes over a day.
2. You can rebuild the index from your existing block chain file. The index is in fact disposable.. To do this you move the database files out of the way, preserving blk0001.dat then load it using the -loadblock=blk0001.dat parameter. This does not connect to anyone, so doesn't matter what config file you have. A bit faster method. Takes about hour and a half on my hardware.
3. Use the provided block chain files. These files are taken off a working node, which is periodically rebuilt using the first method, because that results in the least bloated files (less orphans). This is the fastest method. As an added measure, you are advised to run -checkblocks=0 -checklevel=6 to do an full check of all blocks in the database for consistency.
The controlled topology configuration we advise at times of trouble is intended to resolve this corruption, by preventing the bogus node to talk directly to you. We already know such bad blocks are *not* relayed. The bad block could corrupt the local on-disk block index of the relaying node, but it will not relay it. Weird..
This topology also helps with the other attack we observed these days.
I for one, would love to hear from anyone who has any pointer how the block index issue can be resolved.
