Elacoin dev continues to be incompetent, for the second time... Read on...

[Hazard]

Elacoin dev just rereleased... and pushed a git out with the following value set:

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 1000000); // Elacoin: starting difficulty

Apparently this fool thinks this controls the starting difficulty. What this variable actually controls is the minimum proof of work value after recalculation.

The funny thing about the proof of work value, is that it's inversely related to difficulty. Meaning, what he has done here will cause difficulty to skyrocket to absolutely insane levels come the first retarget.

Enjoy!

[1714928493]

1714928493

[1714928493]

1714928493

[1714928493]

1714928493

[tytanick]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

[Hazard]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

[Milkshake]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

[Hazard]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

[Milkshake]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

[Hazard]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

False.

That variable is in place to stop the difficulty from ever getting too low. It serves as the floor for difficulty, basically. There is enough documentation online to prove this.

You have increased that floor from 20 to 1000000. Ergo, you have INCREASED difficulty by an insane amount.

You've already proven yourself to be incompetent. Don't even act like you know a damn thing about how bitcoin works, or coin creation in general.

[centenary]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

False.

That variable is in place to stop the difficulty from ever getting too low. It serves as the floor for difficulty, basically. There is enough documentation online to prove this.

You have increased that floor from 20 to 1000000. Ergo, you have INCREASED difficulty by an insane amount.

You've already proven yourself to be incompetent. Don't even act like you know a damn thing about how bitcoin works, or coin creation in general.

Er, those values are preceded by a right-shift operator.  By changing the amount of right-shift from 20 to 1000000, he actually is making the value of bnProofOfWorkLimit smaller, not larger.  In fact, because uint256 doesn't actually have 1000000 bits, by setting the amount of right-shift to 1000000, he's basically setting the value of bnProofOfWorkLimit to 0.

I support all of your other posts, but this one isn't technically accurate.

[jomay]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

False.

That variable is in place to stop the difficulty from ever getting too low. It serves as the floor for difficulty, basically. There is enough documentation online to prove this.

You have increased that floor from 20 to 1000000. Ergo, you have INCREASED difficulty by an insane amount.

You've already proven yourself to be incompetent. Don't even act like you know a damn thing about how bitcoin works, or coin creation in general.

Er, those values are preceded by a right-shift operator.  By changing the amount of right-shift from 20 to 1000000, he actually is making the value of bnProofOfWorkLimit smaller, not larger.  In fact, because uint256 doesn't actually have 1000000 bits, by setting the amount of right-shift to 1000000, he's basically setting the value of bnProofOfWorkLimit to 0.

I support all of your other posts, but this one isn't technically accurate.

+1

Code:

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 1000000); // Elacoin: starting difficulty

I don't know what bnProofOfWorkLimit does, but whether he ">> 1000000" or ">> 2048" or "= 0" does not matter. At least if CBigNum implements >> correctly.

bnProofOfWorkLimit is a 256 byte integer, it has 8*256=2048 bit and Milkshake shifted all bits out. Kinda pointless.

[Hazard]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

False.

That variable is in place to stop the difficulty from ever getting too low. It serves as the floor for difficulty, basically. There is enough documentation online to prove this.

You have increased that floor from 20 to 1000000. Ergo, you have INCREASED difficulty by an insane amount.

You've already proven yourself to be incompetent. Don't even act like you know a damn thing about how bitcoin works, or coin creation in general.

Er, those values are preceded by a right-shift operator.  By changing the amount of right-shift from 20 to 1000000, he actually is making the value of bnProofOfWorkLimit smaller, not larger.  In fact, because uint256 doesn't actually have 1000000 bits, by setting the amount of right-shift to 1000000, he's basically setting the value of bnProofOfWorkLimit to 0.

I support all of your other posts, but this one isn't technically accurate.

This value in testnet is specifically decreased to make block generation easier. It would follow that increasing it would make block generation harder.

[centenary]

yep but he changed it
https://github.com/elacoin/elacoin/commit/0d3db7e9da6b12801439d24e32250c0243021b18

I'm sure many people are still running the 1000000 client.

And it's hilarious that crap like this even gets pushed out. This guy has no idea what he's doing in the code. He's just editing random variables and hoping they do what he wants.

You do realize it is >> right? higher >> means a lower number.

Perhaps I phrased that poorly. Or in a way that you did not understand. Anyway...

Allow me to rephrase it another way. By using an example. On bitcoin testnet, that variable in particular is decreased in order to reduce the minimum difficulty.

You, however, decided to increase it from it's starting value of 20, to an insane value of 1000000. You are in for some nasty difficulty spikes because of this.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

False.

That variable is in place to stop the difficulty from ever getting too low. It serves as the floor for difficulty, basically. There is enough documentation online to prove this.

You have increased that floor from 20 to 1000000. Ergo, you have INCREASED difficulty by an insane amount.

You've already proven yourself to be incompetent. Don't even act like you know a damn thing about how bitcoin works, or coin creation in general.

Er, those values are preceded by a right-shift operator.  By changing the amount of right-shift from 20 to 1000000, he actually is making the value of bnProofOfWorkLimit smaller, not larger.  In fact, because uint256 doesn't actually have 1000000 bits, by setting the amount of right-shift to 1000000, he's basically setting the value of bnProofOfWorkLimit to 0.

I support all of your other posts, but this one isn't technically accurate.

This value in testnet is specifically decreased to make block generation easier. It would follow that increasing it would make block generation harder.

Yes, and by right-shifting by 1000000 bits, he's setting the value of bnProofOfWorkLimit to 0.

I don't know if you're a coder, so I'll try to break it down.  Right-shifting by 1 will divide the value of bnProofOfWorkLimit by 2^1.  Right-shifting by 2 will divide the value of bnProofWorkLimit by 2^2.  Right-shifting by 1000000 will divide the value of bnProofOfWorkLimit by 2^1000000.  This will cause the value of bnProofOfWorkLimit to be extremely tiny.  Since computers don't actually have that much precision, bnProofOfWorkLimit actually gets set to 0.

As you said, decreasing the value of bnProofOfWorkLimit value makes block generation easier.  He successfully did so by setting bnProofOfWorkLimit to 0.

[rbaggio]

....... awkward ........

[Hazard]

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 1000000);

I'm aware of what is occuring. I am trying to convey that the higher you set that value, the higher the floor for the difficulty becomes. And by that value, I mean the bolded value. You seem to be confused as to what I'm referring to. I'm referring to the BOLDED number, not the final outcome of bnProofOfWorkLimit. Sorry if I haven't been entirely clear on that.

Bitcoin has theirs set at 35.
Litecoin is 20.

His is 1000000. Don't you see the problem there?

[tytanick]

anyway he changed to 40, whats the poind of trolling him ?
Why everybody hates everybody ? jelaous ? becaous he made own coin ?
Come one people, just take eachother hands and love eachoder (not gay way :PP or gay if u want

[Hazard]

anyway he changed to 40, whats the poind of trolling him ?
Why everybody hates everybody ? jelaous ? becaous he made own coin ?
Come one people, just take eachother hands and love eachoder (not gay way :PP or gay if u want

The fact that anyone would release code with that value set at a damn million indicates the developer has no idea what the hell he's doing, and therefore has no business creating a coin.

[Hazard]

He also had TWO releases where he listed the genesis block as index 1 in the checkpoints file. It is supposed to be index 0.

There's so many amateur mistakes with this coin, nobody should be wasting their precious hashes on it.

[skyangel]

Yes, and by right-shifting by 1000000 bits, he's setting the value of bnProofOfWorkLimit to 0.

Correct.

Anybody using >> 10000 just doesn't know what he's doing.

Also you can see from getinfo that this coin started at 0 difficulty.

[WindMaster]

LOL:

Code:

ProcessBlock: ORPHAN BLOCK, prev=2334c82ec9792a6686b3
received block 2334c82ec9792a6686b3
ProcessBlock: ACCEPTED
received block f65939c127dff00bed0f
REORGANIZE
REORGANIZE: Disconnect 3 blocks; cd163f96d850e78ea526..667b7f2fdee024438293
REORGANIZE: Connect 4 blocks; cd163f96d850e78ea526..652cb0993fc232a1ea5e
Segmentation fault
$

[Hazard]

Correct.

Anybody using >> 10000 just doesn't know what he's doing.

Also you can see from getinfo that this coin started at 0 difficulty.

Almost true. There is no absolute zero difficulty in bitcoin. It started at 0.00024414

Anyway, my entire point was that he was trying to use this variable to control starting difficulty (incorrectly, at that), when it is not what it is used for at all.

It's a shame that he saw my post and changed it immediately. Would have been very funny if 51% of clients were running the 1000000 version

Goodnight friends.

[jomay]

Correct.

Anybody using >> 10000 just doesn't know what he's doing.

Also you can see from getinfo that this coin started at 0 difficulty.

Almost true. There is no absolute zero difficulty in bitcoin. It started at 0.00024414

Anyway, my entire point was that he was trying to use this variable to control starting difficulty (incorrectly, at that), when it is not what it is used for at all.

It's a shame that he saw my post and changed it immediately. Would have been very funny if 51% of clients were running the 1000000 version

Again, a damn million, 2048, 5739. It just doesn't matter - bnProofOfWorkLimit should be exactly zero.

You may discredit his code, but do it right, man. Otherwise:

[Hazard]

I love that dog.

Anyway, I encourage you all to compile a coin using that insanely high value and see what happens every time you hit a difficulty retarget.

[jomay]

I love that dog.

Anyway, I encourage you all to compile a coin using that insanely high value and see what happens every time you hit a difficulty retarget.

I imagine a value bnProofOfWorkLimit == 0 is not good.

But it will be == 0. It's actually pretty amusing to read the code for >> :

Code:

00416     CBigNum& operator>>=(unsigned int shift)
00417     {
00418         // Note: BN_rshift segfaults on 64-bit if 2^shift is greater than the number
00419         //   if built on ubuntu 9.04 or 9.10, probably depends on version of OpenSSL
00420         CBigNum a = 1;
00421         a <<= shift;
00422         if (BN_cmp(&a, this) > 0)
00423         {
00424             *this = 0;
00425             return *this;
00426         }
00427 
00428         if (!BN_rshift(this, this, shift))
00429             throw bignum_error("CBigNum:operator>>= : BN_rshift failed");
00430         return *this;
00431     }

[WindMaster]

I imagine a value bnProofOfWorkLimit == 0 is not good.

But it will be == 0. It's actually pretty amusing to read the code for >> :

Code:

00416     CBigNum& operator>>=(unsigned int shift)
00417     {
00418         // Note: BN_rshift segfaults on 64-bit if 2^shift is greater than the number
00419         //   if built on ubuntu 9.04 or 9.10, probably depends on version of OpenSSL
00420         CBigNum a = 1;
00421         a <<= shift;
00422         if (BN_cmp(&a, this) > 0)
00423         {
00424             *this = 0;
00425             return *this;
00426         }
00427 
00428         if (!BN_rshift(this, this, shift))
00429             throw bignum_error("CBigNum:operator>>= : BN_rshift failed");
00430         return *this;
00431     }

Core dumped and traced from one of the many elacoind segfaults I'm seeing.  It does indeed segfault in the overloaded >> operator for CBigNum, on Debian 6.0 (so not just old versions of Ubuntu).

[Balthazar]

I wonder to see such target in action  QuantumApocalypse going on

[VelvetLeaf]

We're still waiting for Milkshake's BFL SC photo first.

Link : https://bitcointalk.org/index.php?topic=203881.msg2131011#msg2131011

Nice!, when have you received it?

Today. Nice surprise, didn't even pay for it!

You probably do realize this account is the troll account from another account here. I think it was created in honor of smoothie.

That is correct, but I do have a 30GH/s ASIC from BFL mining, and I received it as a freebie.

No kill-a-watt (they measure power consumption right?), I'll post pics later for the blog post when I've written it up and measured long term performance / stability.

I don't mind the power consumption, BFL is covering electricity bills too.

[AlternativeCypt]

We're still waiting for Milkshake's BFL SC photo first.

https://i.imgur.com/lLS8vVN.png

Nice!, when have you received it?

Today. Nice surprise, didn't even pay for it!

You probably do realize this account is the troll account from another account here. I think it was created in honor of smoothie.

That is correct, but I do have a 30GH/s ASIC from BFL mining, and I received it as a freebie.

No kill-a-watt (they measure power consumption right?), I'll post pics later for the blog post when I've written it up and measured long term performance / stability.

I don't mind the power consumption, BFL is covering electricity bills too.

LMFAO

[Impaler]

Yes, and by right-shifting by 1000000 bits, he's setting the value of bnProofOfWorkLimit to 0.

Correct.

Anybody using >> 10000 just doesn't know what he's doing.

Also you can see from getinfo that this coin started at 0 difficulty.

Have too agree with ya their, that piece of code makes me cringe and I would not run ANYTHING that came from that programmers hand.