Quote from: Hazard on May 14, 2013, 08:20:53 AM

Quote from: centenary on May 14, 2013, 08:15:39 AM

Quote from: Hazard on May 14, 2013, 08:10:33 AM

Quote from: Milkshake on May 14, 2013, 08:07:55 AM

Quote from: Hazard on May 14, 2013, 08:05:33 AM

Quote from: Milkshake on May 14, 2013, 08:03:15 AM

Quote from: Hazard on May 14, 2013, 08:02:33 AM

Quote from: tytanick on May 14, 2013, 08:01:32 AM

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.