[ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65%

[utahjohn]

@polanskiman
And did you take the "bribe" to keep quiet (I would have and then announced it here LOL)

[1714912630]

1714912630

[1714912630]

1714912630

[1714912630]

1714912630

[1714912630]

1714912630

[1714912630]

1714912630

[jhed]

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]

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?

Code:

diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.

[polanskiman]

@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]

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?

Code:

diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.

What's your wallet version?

[polanskiman]

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#msg8115151

What is your diamond.conf config? Please post it here.

[jhed]

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?

Code:

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]

uh?
http://cryptohunger.com:81/

Thanks. Added to the OP.

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]

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#msg8115151

What 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]

Not getting this at all.

Please read: https://bitcointalk.org/index.php?topic=580725.msg8115151#msg8115151

What 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.

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]

Not getting this at all.

Please read: https://bitcointalk.org/index.php?topic=580725.msg8115151#msg8115151

What 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.

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]

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.

[danbi]

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).

[ilusm]

Dev,pls work harder and bring us to da moon!

[cryptonit]

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!

Announcement: Design Contest

beat https://bitcointalk.org/index.php?topic=580725.msg7964250#msg7964250

which failed to follow the requirement

we wont change the coin as main logo itself
(or just in a very similar improved version)

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

DMD Multipool Lotto
next drawing 3.august 100 DMD
http://multipool.bit.diamonds/

[paladin281978]

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?

[polanskiman]

Not getting this at all.

Please read: https://bitcointalk.org/index.php?topic=580725.msg8115151#msg8115151

What 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.

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]

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?

I suppose those not accepted are minted. Correct?

[jhed]

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]

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?

I suppose those not accepted are minted. Correct?

Correct