Why does this site give so much importance to popularity?

Doge and Blackcoin rated higher than XMR and BBR? Because the devs are working on foundations and innovation instead of marketing? Please.

As I've stated enough times, I think this is overblown, but I hate that this is a hammer being used against a coin when people can't find an actual argument based upon technical or economic merits.  So:

if there's not a stratum implementation available within 1 week to allow cbuchner1 to demonstrate his follow-through with open sourcing a miner, I will create one (clarifying:  a GPU miner, not a stratum. grin.  i'm not that masochistic.), integrated with simpleminer.  It won't be pretty, it will be a horrible hack to get it to compile (I'm cmake-clueless), but in a form that someone with c_z's expertise will be able to integrate more cleanly.

I'll start on the core of this now and post some regular updates.

(But please please please - someone do the stratum integration instead.  There's a lovely bounty waiting for you if you do.  The resulting product will be a much better tool for everyone to use, and I'd rather spend my time doing things that I actually believe are beneficial for BBR, not just combatting an overblown claim being used by detractors.)

I am just trying to advice you to make you richer ;  Keep some BBR (I am sure you already do). Release the miner - maybe with some announcement, countdown or something similar. Promote the event (miner releasing), promote the coin. And then watch the price rise. Pumps and dumps but going up like monero or other interesting coins. You still can use your miner, mined coins will have higher value and your reserves will have higher value... Otherwise people will loose interest - in fact they are already loosing. And it is a pity.

We had some issues with GCC 4.9/ArchLinux building too, we fix them in this commit
https://github.com/monero-project/bitmonero/commit/9853ba8e0636ba6f1043bb4f52caff19fe54c8ac

You can try merging that and seeing if it fixes it

I was going over the features I readily disagree with. I'm not sure about the tx prefixing stuff, because I still don't entirely understand what it solves. It seems that he's making it so that you can't mixin outputs from before checkpoints as inputs, which means you're relying on centralized checkpointing dictated by him to establish what inputs are to be used.

But, as you said, if this becomes useful, we can always implement it in Monero without a lot of hassle (the tx_prefix hashing is from the original ByteCoin code and used in signature generation).

crypto_zoidberg knows the network code very well and is good at patching things relating to it, and the alerts system is a good idea and should be integrated into ByteCoin/Monero/etc.

It's not.

I see no chance of a boolberry takeover. If boolberry did takeover I would probably sell back into bitcoin because it would mean any cryptonote coin can be destroyed by a features for feature sake coin. Which is what boolberry and litecoin are. The proof of work. The alias. The tx modifications. It's just an attempt to differentiate for the sake of marketing.

It's litecoin all over again.

I'm going to disagree with #2 - I think the issue with aliases is that they haven't been yet pushed hard enough.  For example, there should be an alias rebinding mechanism (perhaps using a tx fee and a signature from the originally bound key).  

1) Using the block header hashes as the scratchpad was intended to keep individual miners full nodes, but this was naive and pools simply send the (tiny) headers out to the miners themselves. There is lots of discussion about how to prevent pool centralization in Bitcoin lately, and Boolberry's solution has been criticized as being "the worst of both worlds" (requires lots of extra data to hash, but doesn't prevent pooled/centralized mining at all).

Since cn_slow_hash created 2MB scratchpad, it's have to cover all this data, that's why they use 2²⁰ iterations, and side-effect from this pretty slow work (about 500ms on normal laptop, twice faster on normal pc with suitable cpu cache). It may slow down synchronisation process at downloading blockchain (that is not a big problem) and theoretically it may be possible to attack network - connect and send a random block to make peer calculate slow_hash for useless fake block.

So, putting all together, we want to have:
1. Wide CPU instruction set
2. Memory-oriented algo
3. Small work time.

Realizing it, we've  tried to take a step to the side.

Idea of using blockchain data as scratchpad resulted in this hash function:
.......

2) Aliases attach additional, permanent identity pieces to your addresses and should probably be avoided in my opinion.

3) The mandatory mixin=n for txouts doesn't solve fundamental issues with privacy relating to ring signatures. Monero has the same issues, but this will be discussed in an upcoming softfork proposal I'm coming up with thanks to some guidance from gmaxwell. Right now, because Monero is mostly used speculatively, it's not really an issue and is probably a boon to trading over the chain. Further, Boolberry's feature attaches identifier information to outputs which may be further used in analysis to identify spenders.

So did you try adding it to the linker command line?

I reported this bug a couple of months ago..  
Add -lpthread after ${Boost_LIBRARIES} in src/CMakeLists.txt (and tests/CMakeLists.txt if wanted)

include_directories(SYSTEM ${Boost_INCLUDE_DIRS})
if(MINGW)
  set(Boost_LIBRARIES "${Boost_LIBRARIES};ws2_32;mswsock")
elseif(NOT MSVC)
if(NOT APPLE)
  set(Boost_LIBRARIES "${Boost_LIBRARIES};rt;pthread")
endif()
endif()

/tmp/cc5ITsCl.ltrans25.ltrans.o: In function `handle_update_maintainers_info(boost::program_options::variables_map&)':
cc5ITsCl.ltrans25.o:(.text+0x139f): undefined reference to `currency::get_blob_hash(std::string const&)'
cc5ITsCl.ltrans25.o:(.text+0x13c0): undefined reference to `crypto::crypto_ops::generate_signature(crypto::hash const&, crypto::public_key const&, crypto::secret_key const&, crypto::signature&)'
/tmp/cc5ITsCl.ltrans28.ltrans.o: In function `generate_and_print_keys()':
cc5ITsCl.ltrans28.o:(.text+0x6c5): undefined reference to `crypto::crypto_ops::generate_keys(crypto::public_key&, crypto::secret_key&)'
/tmp/cc5ITsCl.ltrans28.ltrans.o: In function `main':
cc5ITsCl.ltrans28.o:(.text.startup+0x1a4): undefined reference to `command_line::arg_help'
cc5ITsCl.ltrans28.o:(.text.startup+0x490): undefined reference to `command_line::arg_help'
collect2: error: ld returned 1 exit status
make[3]: *** [src/connectivity_tool] Error 1
make[3]: Leaving directory `/home/nirv/boolberry/build/release'
make[2]: *** [src/CMakeFiles/connectivity_tool.dir/all] Error 2
make[2]: Leaving directory `/home/nirv/boolberry/build/release'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/nirv/boolberry/build/release'
make: *** [build-release] Error 2

Im getting compiling errors while it is trying to compile the connectivity_tool on ubuntu 14.04. Using Win7x64 for now until I can get some help to get it to compile.

Zoidberg, Thanks for your hard work.
Although you are a very good and efficient developer,
I think you must find a team to work with you, not do all the things yourself

just waiting for someone to make a miner that supports stratum, something like lucasjones's cpuminer-multi or wolf's cpuminer-multi.  the pools would take off if there was something other than simpleminer to work with.

Guys,best pool I found on OP has only 30 MH/s,and this pool founds only 1 block in 6-10 hours...Devs are using  closed pool for this coin and they have another(not announced miner)Please do not be fools.Try to think critically.

My hashrate halved with the new code on github (my old code was 3 or 4 days ago) .
And yes I did check the hashrate just before changing version, so that's not a difficulty increase!

I use Linux.

I've made some miner-specific changes because I know simpleminer better and didn't want to risk breaking the daemon.  It also uses double the scratchpad memory, which seems, again, like something fine short-term in the miner but a design that would need to be adjusted to be used as a permanent solution in the daemon.

This commit improves the speed of simpleminer on my test box by 57%.

I didn't expect the gains to be that large based upon my earlier calculations, but with the increasing scratchpad size, they actually helped a ton.

There are two important consequences of this:
  (a)  I *believe* this change will be more beneficial -- right now -- for machines with 4-8MB cache than for huge beasts like EC2 (10-20MB L3);  the big machines still have enough cache to hold the entire scratchpad, and my experiments suggest that they haven't seen the same kind of slowdown that my i7 has.

  (b)  It covers a pretty reasonable part of the gap to the very rough estimate of the gpu miner performance.  What happens there depends, of course, on what's happened with caching on the GPU as well.

https://github.com/dave-andersen/boolberry/commit/1732617f7fada01551a7f7c496e9fafeb1d66fe0

There's one drawback to doing it only in the miner, of course:  It promotes pooled mining instead of having lots of solo miners.  That's probably inevitable in the long run, because it's always easier to optimize a miner if you don't need to worry about the stability and portability of the daemon itself.  But we should probably think about letting people mine locally using simpleminer (or is it already possible and I'm being silly?) and/or whatever is developed on the stratum front, so that all miners are on the same footing whether they choose to pool or solo.

I consider this beta.  It's linux-only, and I *hope* I didn't break anything on other platforms.  Feedback appreciated - I really only have Linux and MacOS to test on.  If reports come back positive and this doesn't break building / running on windows or non-ubuntu Linux platforms, I'll submit it as a pull request to the boss.

If you get rich off of this one, *now* I'll point out where you can send a few berries.  grin.
BBR:  1CgXH4mgEWULe97EKW2LrcQp68MZJ7d4cffA6umkHa5ZK12Rt8M4nCyHYBzjx2ZXkuV7GPh8iFwrJat s4x4sTkByCZZqL1F

Happy mining!

(btw:  I've got some high-priority day job stuff to take care of for a bit.  I'll watch for huge bugs, but adding async/longpoll was delayed a bit by getting these optimizations done.  Might be next week or weekend.)

we would need to talk to LucasJones and/or Zone117x about adding stratum support.