Quote from: canonsburg on July 28, 2014, 09:34:11 PM

Are you dense or something? This was code that was part of the original reference CryptoNote code. Had nothing to do with Monero. In fact, it took Monero to fix this "bug".

No, are you dense?

Why did such a bug ever make it past the audit stage? unless there was
1) no audit beyond initial copy and paste, (he team lacked the competence to notice such a trivial un-optimization)
2) or it was intentionally left crippled once again in the monero fork.

BBR never had such a intentional crippling.

Quote from: smooth on July 28, 2014, 09:46:37 PM

Quote from: desil on July 28, 2014, 09:38:02 PM

That is untrue as the performance of the private GPU miner was limited by the increasing scratchpad size which is now effectively much greater in size than nearly a month ago. The ever increasing scratchpad size decreases the performance of the privite gpu miner by each passing day.

So in other words the private GPU miner(s) had a huge early advantage that can never be replicated by anyone ever again in the future. Sounds exactly like an instamine to me.

I can't pretend to be happy about people not on level playing grounds. The news of private GPU miner was a big negative for BBR and will be constantly brought up. I'm not sure it can ever escape from it.
however premine in my mind usually means mining large amount of early blocks and waiting for huge appreciation..
What do you think exactly happened to those early GPU mined coins? they were held gradually losing value until today?
Large amount was dumped and re-distributed filling market orders in regular batches, of course there was costs associated with mining them that needed to be recouped, and the miners in question seeked a guaranteed quick profit. In this sense there is not a single entity who now controls a huge portion purely from advantaged mining as suggested. (buying is another story)

Quote from: smooth on July 28, 2014, 09:50:46 PM

Quote from: Anotheranonlol on July 28, 2014, 09:46:53 PM

Why did such a bug ever make it past the audit stage? unless there was
1) no audit beyond initial copy and paste, (he team lacked the competence to notice such a trivial un-optimization)

I guess you were volunteering to audit the tens of thousands of lines of code with no design documentation and no comments?

For that matter, if you are still volunteering to do this, we have openings, since the process is ongoing.

Ten's of thousands of lines of code maybe but are you suggesting to me no eyes were on slow_hash specifically. Come off it.
I don't have to volunteer to audit the base myself in order to criticize others (the dev team who actually launched the damn thing) for not spotting it..
you know yourself this was an incredibly obvious thing to notice.