Quote from: stellarman on August 05, 2014, 01:34:27 AM

I'm new in this thread, but I have been watching and investing in Monero for several months.

Now that I have studied Boolberry a bit, I am puzzled as to why the price of BBR is less than a tenth the price of XMR. There are actually a couple of features of BBR that I think have advantages over XMR. It seem to me that the prices probably should be closer to parity.

I guess it is a bit weird to ask this here, but is there something I'm missing that has led to this big price difference?

I might buy some BBR if I can wrap my wits around this discrepancy.

Just recently dga gave perspective to the relevant events regarding private GPU miner - which is putting instamine FUD to the rest.

Quote from: dga on August 02, 2014, 02:04:33 AM

Quote from: smooth on August 01, 2014, 10:05:46 PM

Quote from: drawingthemoon on August 01, 2014, 09:51:49 PM

Same rules apply to people bashing BBR. Tainting it because of christian developing a private miner?

I think they likely to be quite different. My last post estimated that roughly 2% of XMR coins were mined before the public miner was un-de-optimzied. What is corresponding percentage of BBR coins? Since the emission curve is reasonable I still don't think the number is that large (compared to absurdly instamined coins -- and shills for these coins on this thread you know who you are) but it still may be higher than XMR. Or perhaps not. I haven't really been following it so I don't know.

They're surprisingly similar in terms of %age. The gap for the de-optimized miner vs a GPU miner was larger (20x gap vs 5x gap), but as we all know, it's easier to bring more GPUs to bear on mining unless you have a botnet. Boolberry is currently around 5% mined, and it's had a public GPU miner for several weeks. The timeline for the un-de-optimization can be read pretty clearly from the git commit history on bitmonero:

https://github.com/monero-project/bitmonero/commits/master/src/crypto/slow-hash.c

Block 1 was mined at 2014-04-18 10:49:53, and Noodle's first optimization was committed into the repository on May 7, but recall that those initial optimizations were still in the 5-10 h/s range. The more significant one was May 21, and then the current-generation "hyper-optimized" miners came into play a week or so after that.

I think it's important to distinguish between "de-optimized" (which I'd say was the state before the May 21 commit) and "not yet optimized". What Noodle got things to on May 21 was what a reasonable, sane person might think of as an implementation of CryptoNite. The things that followed were architecture-specific optimizations, and we can have a separate fight about the degree to which devs should feel required to release vector-optimized code in a first release vs. letting the legions of optimizers handle it for them at the cost of some free coins.

This is around block 50,000 in the XMR blockchain.

mbk's GPU miner for Boolberry was released July 19:

https://bitcointalk.org/index.php?topic=693118.msg7928171#msg7928171

This is around block 45,000 in the BBR blockchain.

That's frighteningly similar, all things considered. I hadn't actually done that analysis before -- interesting.

I think it's worth differentiating "unfair" from "the @*ing dev cheated". I'm not entirely sure why I feel so strongly about this, but I do -- I think it's because it destroys any trust I'd have in the developers, and when you're dealing with *money*, it's important to have a dev team you can trust -- otherwise, what else did they hide in the code that you haven't had a chance to find yet?

I'm pretty convinced that neither the XMR or Boolberry devs cheated in this way. I'm also pretty convinced that the Bytecoin devs did: that code was so de-optimized it was a joke, and I think that all of us who touched it concur. But it's not the XMR team's fault that they inherited something sneaky in the code and acted to root it out. And the BBR initial implementation was pretty well optimized -- the things that otila and wolf did on top of it take work and are beyond what "the average developer skilled in the art" (but not interesting in to-the-metal optimization) should be expected to do.