utahjohn
|
|
August 01, 2014, 01:56:51 AM |
|
@polanskiman And did you take the "bribe" to keep quiet (I would have and then announced it here LOL)
|
|
|
|
jhed
Newbie
Offline
Activity: 26
Merit: 0
|
|
August 01, 2014, 02:03:38 AM |
|
jhed Newbie * Online Online
Activity: 3 Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me.
|
|
|
|
jhed
Newbie
Offline
Activity: 26
Merit: 0
|
|
August 01, 2014, 02:12:29 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.
|
|
|
|
polanskiman
|
|
August 01, 2014, 02:17:36 AM |
|
@polanskiman And did you take the "bribe" to keep quiet (I would have and then announced it here LOL)
It was not a bribe. The DMD he proposed were actually coins that I did NOT see coming to my wallet one day while mining in his pool. No transaction happened during a period of 6 hours when in fact transaction were supposed to happen every hour. We never really figured out why but he was fast to claim that it might have been my internet, my miner etc etc. What I wanted was a clear explanation. Never had it. At least he proposed which somehow was a nice thing to do but I didn't want to take the coins as it was not crystal clear what the problem really was.
|
|
|
|
polanskiman
|
|
August 01, 2014, 02:19:56 AM Last edit: August 01, 2014, 02:39:09 AM by polanskiman |
|
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.
What's your wallet version?
|
|
|
|
polanskiman
|
|
August 01, 2014, 02:22:10 AM |
|
jhed Newbie * Online Online
Activity: 3 Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me. Not getting this at all. Please read: https://bitcointalk.org/index.php?topic=580725.msg8115151#msg8115151What is your diamond.conf config? Please post it here.
|
|
|
|
jhed
Newbie
Offline
Activity: 26
Merit: 0
|
|
August 01, 2014, 02:33:21 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.
What's you wallet version? Diamond v2.0.3 https://github.com/DMDcoin/Diamond/archive/Diamond-2.0.3.tar.gz
|
|
|
|
srcxxx
|
|
August 01, 2014, 02:41:24 AM |
|
ALso pretty sure they require grs-sgminer to mine diamondcoin on their pool (the srcxxx connection) I thought http://cryptohunger.com:81/ was taken out of the advertised pools. Why is it back? I also see that you managed to to know the fee %. . And people are still mining there. It's absurd. Yeah the grs-sgminer was discovered (by cryptonit i believe) to have hidden fees built-into it too ... Take it back off OP There are no hidden fees! The hashrate is multiplied by the (100% - fee). So you are getting paid for the value displayed in your grs-sgminer. Period. PS: The pool is on the latest code from github and has blockchain from dmdchain20140731-fast.zip.
|
|
|
|
jhed
Newbie
Offline
Activity: 26
Merit: 0
|
|
August 01, 2014, 02:57:19 AM |
|
jhed Newbie * Online Online
Activity: 3 Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me. Not getting this at all. Please read: https://bitcointalk.org/index.php?topic=580725.msg8115151#msg8115151What is your diamond.conf config? Please post it here. 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.
|
|
|
|
polanskiman
|
|
August 01, 2014, 03:05:07 AM Last edit: August 01, 2014, 04:28:53 AM by polanskiman |
|
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 fixe.
|
|
|
|
jhed
Newbie
Offline
Activity: 26
Merit: 0
|
|
August 01, 2014, 04:39:56 AM |
|
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.
|
|
|
|
danbi
|
|
August 01, 2014, 05:26:14 AM |
|
If you all are actually able to transmit money into Cryptsy than you are on the correct chain. If I was able to from this chain, than I'm on the correct chain. Crypsty couldn't possibly be connected to both chains. Isn't that right?
Cryptsy is not a measure for the correct chain. It will be very unfortunate if they are on a fork, but this has happened many times before and was sorted out. Frustrating, yes. They can't be on both chains, correct.
|
BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
|
|
|
danbi
|
|
August 01, 2014, 05:36:55 AM |
|
jhed Newbie * Online Online
Activity: 3 Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me. 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).
|
BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
|
|
|
ilusm
|
|
August 01, 2014, 05:38:27 AM |
|
Dev,pls work harder and bring us to da moon!
|
|
|
|
|
paladin281978
|
|
August 01, 2014, 07:11:54 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?
|
|
|
|
polanskiman
|
|
August 01, 2014, 07:15:56 AM Last edit: August 01, 2014, 07:30:25 AM by polanskiman |
|
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. 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.
|
|
|
|
polanskiman
|
|
August 01, 2014, 07:18:22 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?
|
|
|
|
jhed
Newbie
Offline
Activity: 26
Merit: 0
|
|
August 01, 2014, 07:24:12 AM |
|
jhed Newbie * Online Online
Activity: 3 Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me. 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?
|
|
|
|
paladin281978
|
|
August 01, 2014, 07:53:09 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
|
|
|
|
|