Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65% - page 744. (Read 1260636 times)

I can't even open the wallet with the "Assertion failed" error.
Does that mean i'm on the wrong fork?

If you are on the wrong fork... YES.

So do we download the blockchain+data file from OP, and replace?

No. :-)

This is the thing we all want -- no specific configuration, "it just runs". Trust me, we *all* want just that. I for one, would love to shut down 193.68.21.19 and not have to watch it every single day!

However, we are in situation where there are bugs, that we are not aware of and that some (one or more) attacker knows about. They might not know what the bugs are and how to fix it, but they know that by triggering them our network is disrupted.

We do this restrictive configuration therefore in order to prevent them from doing just that and have more time to analyze the code and *fix* the bugs instead of babysitting the network.

As others have already said, your suggestions are not helping. We went through all this several months ago, when the Diamond network was halted (that bug is now fixed, along with many more allowing other abuse). We go trough the same story about every month now, as getting rid of Diamond is apparently attractive for some.

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.

Can someone please help.

I opened my wallet earlier today without any problems.
A little while ago I opened wallet and it would not sinc.
I closed and re-opened the wallet and I now have the same problem as above that jhed had.
I have the latest wallet and all was good till half an hour ago.
What can I do to fix the problem?

Thanks

is it safe to replace connect with addnode now, or better wait?
i'd be happy to contribute a clean node to the network.

That would be normal. You can put as many connect=IP as you wish. You will connect to each one of them, and only to those.

You can read starting there and posts below: https://bitcointalksearch.org/topic/m.7856040

I just discovered something interesting while clean syncing another wallet (KARMA which hardforked from scrypt to X11)  I put two connect= lines in config to different masternodes and both of them are being used

polanskiman
 ok 

Then it's "normal". Your coins compete with other's coin if I understood this correctly. You still keep the coin-age if the minting failed.

The reason you have many failed attempts is probably due to the fact that you ended up in the wrong fork for a while, or like with me, that you are far from nodes and therefore there is a connection lag. If you see my wallet you would panic

As I have been explained by Danbi and Cryptonit, this is purely cosmetic. Nothing to worry about.

no, most wallets didn't have addnode or connect because it's isn't on by default.
also please understand the difference between addnode and connect.
some people added connect or addnode to try to be on the right chain AFTER the attack, as danbi suggested, and it worked.
now when it's stabilised, everybody will remove the connect and eventually keep addnode.

Correct

Danbi,

Did you not just illustrate the problem here? Everyone's diamond.conf was configured with a single addnode. All the attacker had to do was compromise the block chain at 193.68.21.19 and the whole diamond network was forked.

Unless it is in fact a bug as polanskiman is suggesting.

In any case, wouldn't it be a good idea to do away with the single point of failure and let the network be decentralized as it was designed to be? Remove all "addnodes" and "connect" as well as remove the "listen=0" and "noirc=0"  statements and let the software do it's thing to find out on it's own which chain to use?

I suppose those not accepted are minted. Correct?

Google is your friend. You will understand. You need to do a little research by yourself and cannot expect others to do the hard work for you. I and others have already explained but seems you are not willing to understand.

Hell, if you were a bit more curious you would look at past pages in this thread and you'll get your answer.

danbi



Wallet 2.0.3
I'm on the right chain
Difficulty in a wallet it is equal difficulty on dmdpool.digsys.bg
conf file:
listen=0
noirc=1
connect=193.68.21.19

but why there are a lot of not accepted?

Vote for Diamond DMD on

click pic or this link https://www.mintpal.com/voting#DMD

place #114  now

paying 1 DMD to everyone who reached a new rank

so first one reporting #113 and walletaddress
@ http://bit.diamonds/community/index.php/topic,16.0.html
gets 1 DMD
IMPORTANT only claim rewards on
http://bit.diamonds/community/index.php/topic,16.0.html[/b][/color]

Dont forget our Design Contest!


so if u think u can do better
and stay with design and color scheme that fit to our coin logo and our website
http://bit.diamonds/promo.html

please show us ur skills

we will pay some DMD for each serious attempt and at least 200 DMD for the great winner!
(required is logo (have to be very close to original) buttons and icons for ANN thread
and some examples of promo banners where we get all the used art modules to create more similar looking banners)
(if there is nothing that fullfil requirements we can also choose no winner..)

contest will run over a month we will select winner in first week of september