Bitcoin Forum
March 28, 2024, 04:41:27 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Elacoin dev continues to be incompetent, for the second time... Read on...  (Read 2606 times)
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 07:58:33 AM
 #1

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

Quote
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! Smiley

Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711644087
Hero Member
*
Offline Offline

Posts: 1711644087

View Profile Personal Message (Offline)

Ignore
1711644087
Reply with quote  #2

1711644087
Report to moderator
tytanick
Legendary
*
Offline Offline

Activity: 2660
Merit: 1096


Simplemining.net Admin


View Profile WWW
May 14, 2013, 08:01:32 AM
 #2

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

Manage your GPU farm the easy way with Mining OS (30 days free):  SimpleMining.net
Support available at Discord: https://simplemining.net/page/discord and admin@simplemining.net
Bitcointalk thread: https://bitcointalk.org/index.php?topic=1541084.0
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:02:33 AM
 #3

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
Member
**
Offline Offline

Activity: 98
Merit: 10


Milkshake


View Profile
May 14, 2013, 08:03:15 AM
 #4

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.

TradeFortress has left me negative trust and has provided no proof to substantiate his claim. He has done this to discredit me as I am investigating him.
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:05:33 AM
 #5

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
Member
**
Offline Offline

Activity: 98
Merit: 10


Milkshake


View Profile
May 14, 2013, 08:07:55 AM
 #6

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.

TradeFortress has left me negative trust and has provided no proof to substantiate his claim. He has done this to discredit me as I am investigating him.
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:10:33 AM
 #7

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
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 14, 2013, 08:15:39 AM
 #8

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
Full Member
***
Offline Offline

Activity: 167
Merit: 100


View Profile
May 14, 2013, 08:18:44 AM
 #9

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.

BTC 1NoV8NFSB7eiuK2aABFtBTdUdXhbEdG7Ss
LTC LaFyWSfzKY7CKwwmbxhyf8S2iJvfT7JFtL YAC YKKwR5B64Z9ww971J42vEGVPaema623Tz6
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:20:53 AM
 #10

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
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 14, 2013, 08:24:26 AM
 #11

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
Newbie
*
Offline Offline

Activity: 35
Merit: 0



View Profile
May 14, 2013, 08:28:32 AM
 #12

....... awkward ........
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:28:46 AM
 #13

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
Legendary
*
Offline Offline

Activity: 2660
Merit: 1096


Simplemining.net Admin


View Profile WWW
May 14, 2013, 08:32:17 AM
 #14

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 Cheesy

Manage your GPU farm the easy way with Mining OS (30 days free):  SimpleMining.net
Support available at Discord: https://simplemining.net/page/discord and admin@simplemining.net
Bitcointalk thread: https://bitcointalk.org/index.php?topic=1541084.0
Hazard (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:33:17 AM
 #15

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 Cheesy
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 (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:36:35 AM
 #16

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
Sr. Member
****
Offline Offline

Activity: 301
Merit: 260


FLO dev


View Profile
May 14, 2013, 08:40:26 AM
 #17

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
Sr. Member
****
Offline Offline

Activity: 347
Merit: 250


View Profile
May 14, 2013, 08:41:16 AM
 #18

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 (OP)
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile WWW
May 14, 2013, 08:43:43 AM
 #19

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 Cheesy

Goodnight friends.

jomay
Full Member
***
Offline Offline

Activity: 167
Merit: 100


View Profile
May 14, 2013, 08:47:04 AM
 #20

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 Cheesy

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:




BTC 1NoV8NFSB7eiuK2aABFtBTdUdXhbEdG7Ss
LTC LaFyWSfzKY7CKwwmbxhyf8S2iJvfT7JFtL YAC YKKwR5B64Z9ww971J42vEGVPaema623Tz6
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!