pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
August 01, 2014, 08:04:12 AM |
|
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?
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.
|
|
|
|
|
|
|
|
|
Be very wary of relying on JavaScript for security on crypto sites. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
polanskiman
|
|
August 01, 2014, 08:51:47 AM |
|
danbiWallet 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? I suppose those not accepted are minted. Correct? Correct 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.
|
|
|
|
|
utahjohn
|
|
August 01, 2014, 09:18:00 AM |
|
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
|
|
August 01, 2014, 09:19:54 AM Last edit: August 01, 2014, 12:50:00 PM by polanskiman |
|
|
|
|
|
polanskiman
|
|
August 01, 2014, 09:20:57 AM |
|
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 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.
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
August 01, 2014, 09:34:30 AM |
|
is it safe to replace connect with addnode now, or better wait? i'd be happy to contribute a clean node to the network.
|
|
|
|
digi123
|
|
August 01, 2014, 09:37:37 AM |
|
I'm getting this error upon closing and restarting diamondd now. Maybe this has something to do with the chain fork. Is this the place to go for tech support? diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
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
|
|
|
|
danbi
|
|
August 01, 2014, 09:38:33 AM Last edit: August 01, 2014, 09:54:51 AM by danbi |
|
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.
|
BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
|
|
|
danbi
|
|
August 01, 2014, 09:49:02 AM |
|
Let me share a little story with you:
Besides the 193.68.21.19 node I pledged to run for the community (many months ago), I do run few more nodes, which I don't announce but use for tests and .. sometimes as traps for such situations. As I was not paying attention (todo entry already -- provide real-time monitoring) they all were on the wrong chain. All of them were receiving that exact message in their logs. At the 193.68.21.19 they were disconnected/banned too, for the very same reason. I don't want to get too technical on this, but it is apparently this is a form of attack on the network.
The mere reason those nodes ended up that way was they were not properly configured (most are experimental, remember).
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? 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.
|
BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
|
|
|
digi123
|
|
August 01, 2014, 10:12:49 AM |
|
So do we download the blockchain+data file from OP, and replace?
|
|
|
|
polanskiman
|
|
August 01, 2014, 10:18:55 AM |
|
So do we download the blockchain+data file from OP, and replace?
If you are on the wrong fork... YES.
|
|
|
|
digi123
|
|
August 01, 2014, 10:23:28 AM |
|
So do we download the blockchain+data file from OP, and replace?
If you are on the wrong fork... YES. I can't even open the wallet with the "Assertion failed" error. Does that mean i'm on the wrong fork?
|
|
|
|
cryptonit
Legendary
Offline
Activity: 3038
Merit: 1053
bit.diamonds | uNiq.diamonds
|
|
August 01, 2014, 10:55:36 AM |
|
So do we download the blockchain+data file from OP, and replace?
If you are on the wrong fork... YES. I can't even open the wallet with the "Assertion failed" error. Does that mean i'm on the wrong fork? no it mean u got that bad data inserted from one peer this destroyed ur database and u need to start with downloaded blockchain please make sure u run wallet 2.0.3 wallet 2.0.2.x are way more vulnerable to the attacker
|
|
|
|
jepistons
|
|
August 01, 2014, 11:13:09 AM |
|
is anyone else on mining on minep.it ? your Hash 27.74 MH/s
1 workers
2078465.381 DMD est p/day? seems thats a little off :/
|
|
|
|
NineEleven
|
|
August 01, 2014, 11:16:49 AM |
|
Well deleted wallet.dat , yes i lost some 12 dmd but what a hell it was full whith mempoll errors and preventig the wallet from star ; resync the entire blockchain and mining again, for 3 hours by now, i have mined 11 DMD and i'm in sync whit the blockchain. now i have been running a full node almost 9 months and i wold like to do so , for the community , but i'm afraid that if i change the listen=0 to listen=1 that my wallet get on the wrong fork . Is anything i can do to reopen the node without getting in the wrong fork? <OFF TOPIC> and another great job destroying a good coin https://bitcointalk.org/index.php?topic=491058.2800some time do less is more </OFF TOPIC>
|
|
|
|
Mister1k
|
|
August 01, 2014, 11:29:19 AM |
|
is anyone else on mining on minep.it ? your Hash 27.74 MH/s
1 workers
2078465.381 DMD est p/day? seems thats a little off :/
They are not in the game. The Diff is 0. expected shares 1 valid 13 million. They got problems.
|
|
|
|
MineP.it
|
|
August 01, 2014, 11:34:11 AM |
|
is anyone else on mining on minep.it ? your Hash 27.74 MH/s
1 workers
2078465.381 DMD est p/day? seems thats a little off :/
They are not in the game. The Diff is 0. expected shares 1 valid 13 million. They got problems. We're trying to resync to the right chain but yeah.. we got problems atm
|
https://www.minep.it - secure, stable mining pools | 0.75% fees | chat | forums | one login for 40+ pools | unique interface Pools: Bitcoin | BitMark | ConspiracyCoin | CryptCoin | CureCoin | DarkCoin | Digit | DogeCoin | Dvorakoin | FeatherCoin | FractalCoin | Hiro | IsraelCoin | KarmaCoin | Kryptonite | LimeCoinX | Litecoin | MultiWalletCoin | Negotium | NewWorldOrder | OzzieCoin | PyramidsCoin | RootCoin | SaveCoin | Shade | SurvivorCoin | SysCoin | TalkCoin | TitCoin | Trinity | UseCoin | UtopiaCoin | VertCoin | ViaCoin | VirtualCoin | VirtualMiningCoin | WankCoin | WorldCoin | ZetaCoin
|
|
|
cryptonit
Legendary
Offline
Activity: 3038
Merit: 1053
bit.diamonds | uNiq.diamonds
|
|
August 01, 2014, 11:59:47 AM |
|
now i have been running a full node almost 9 months and i wold like to do so , for the community , but i'm afraid that if i change the listen=0 to listen=1 that my wallet get on the wrong fork .
i switched to listen 1 instant after synced up if u run 2.0.3 deleted old peers.dat and have noirc=1 and our addnode entry danger is pretty low to fall away from main chain in future we will provide multiple addnodes which make attack much more complicated my suggestion if everything runs smooth now copy diamond folder with blockchain as backup and change to listen=1
|
|
|
|
cryptonit
Legendary
Offline
Activity: 3038
Merit: 1053
bit.diamonds | uNiq.diamonds
|
|
August 01, 2014, 12:08:50 PM Last edit: August 01, 2014, 12:23:36 PM by cryptonit |
|
i love to talk in pictures : u can see diamond network as a herd of sheep's with a few shepherd dogs and a shepherd shepherd is the foundation shepherd dogs is the network stabilization tool like permanent nodes seed nodes checkpoint wallet filter and so on from time to times wolves try their luck and create confusion but soon repelled by shepherd dogs but some sheep's special if they don't stay close with the shepherd and the shepherd dogs can become victim to the wolves long story short: stay with our suggested conf setting and wallet upgradessome people might suggest: leave the sheep's on their own they will follow their instincts (base wallet code) and live and prosper try that with real sheep's and tell me how many left after a year or two
|
|
|
|
|