You have to actually use it to expect any results... skipping is just a waste of time.
Test each build presented (they are all different) and determine if it's good or bad.
Use a new session name to start over.

In that case, can you also try putting the libhidapi-0.dll from 5.1.0 into the 5.2.0 directory?
The hidapi update in 5.2.0 was supposed to only fix bugs, but maybe it introduced new problems too..

These just disable caching of GPU binaries.
It has nothing to do with CPU mining, and has no effect unless you explicitly enable GPU mining.

Can you make a session with http://luke.dashjr.org/tmp/code/webisect/webisect.php and bisect the difference? Which stick miners?

Pretty sure this is the top FAQ in README. Did you try that already?

I'm afraid kano is continuing his usual campaign of FUD rather than being informative there.  Since generating and transmitting a new block template after a block takes some hundreds of milliseconds, Eloipool lowers the stale rate by a sizable fraction of a percent by issuing work for empty blocks until that's done. From time to time this will result in a random empty block, where otherwise there wouldn't have been a block at all. It's not a bug, and it doesn't fit the behaviour you're describing.

Above the title would at least be annoying IMO.
Maybe floating right of ToC (on pages with it)? That seems unintrusive.
What happened with that company that was okay with just a mention in the page footer?

There's a public (filtered) dump available when the wiki is online/working.

Mostly the same information I said here, but FWIW: http://www.reddit.com/r/Bitcoin/comments/36qje1/why_can_a_block_have_only_1_transaction/crgtdxk

I don't know if I am capable of explaining this without explaining the Bitcoin protocol (and there are plenty of references you could read on it already). Blocks have two pointers, one to all past blocks/transactions, and one to new transactions. Both of these are just pointers, however. When people talk about block size, they are including all the new transactions, but that's just a matter of abstraction.

No, that transaction remains perfectly valid as long as the sender is honest. The blockchain is only needed to provide security against dishonest senders.

Which is the same as any new transactions in the block.

No, any node can arbitrarily record any transactions it wants without miners.
Mining's primary purpose is to provide security for them.

"Empty" blocks are not really empty either: they still include every transaction mined by the prior blocks.
And since 1 block is not sufficient to confirm a transaction, it's really the block 5 down the chain which is beneficial to the transactions in the block mined anyway.

What wizkid057 said.

But one point he made, more explicitly:
The empty blocks found would not have been a "useful" solved block in any case.
They would have been stale shares.

Whether the pool sends an empty block or not, the miner should always begin working on the non-empty block as soon as it its data is received.


... oh, I already said that:

That's (very) obsolete information, and even then says it applies to transactions without a fee - ie, begger transactions.
I'll see about figuring out who/how to update the page. The FAQ under it appears to be up to date.

I'd recommend ignoring kano, since so much of what he says is a lie.

Eligius is one of many responsible miners which have improved script matching to filter out spam/DDoS attacks against the Bitcoin blockchain.
Blacklisting is "punishing or boycotting a list of persons who are disapproved of". Eligius does not do that.
The spam filtering only matches the known spam scripts and not the person(s) responsible for the spam.
Bitcoin Core has similar, but less updated, pattern matching enabled by default for a long time - since Satoshi's maintainership (0.3.x).
Since the advanced patterns mostly match by coincidence and can be easily changed by spammers on a whim, these patterns are not appropriate for a reference codebase, which is the primary goal of the Bitcoin Core project.
Miners are expected to set their own policies anyway, and not rely on the defaults.

Also note the patterns only match spam, and are not in any way related to gambling.
There are many gambling websites which do not perform attacks on Bitcoin.

This one is a simple lie.
The codebase used for Eligius's policy is in my public git repository, and documented on the website.

Yes, at one point Eligius had an interface for MtGox to prioritise their transactions in exchange for hosting and a link at the bottom of MtGox's website.

This just shows his ignorance.
Empty blocks minimise your stale shares.
Eligius (and probably most cluefully operated pools) send them as soon as a new block is found, so that you can begin mining immediately.
This is also followed up with an updated block full of transactions that miners can begin working on as soon as they receive it.
If your internet connection is 10 Gbps, the empty block might waste a few bytes of bandwidth and you'll get the full block immediately to begin working on.
If your internet connection isn't so fast, you'll begin working on the empty block, then transition to the full one as soon as you finish receiving it.
Of course, this is assuming you're using optimised software like BFGMiner. It's quite possible kano's cgminer is buggy in this regard and will mine empty blocks even after it receives the full one - I don't know, not my concern.

I guess he likes to use FUD to promote his pools, since he can't find any logical/real benefit...

You need to publish the source code for this per the GPL license terms.

That's expected. bitcoin-cli is a separate package.

Now that I'm more awake, I notice the init script is being used here.
Check BITCOIND_OPTS in /etc/conf.d/bitcoind - it defaults to:

Can you post the build.log somewhere? Maybe open a bug on Gentoo's bugzilla if you need somewhere to upload the file.

cpuminer was the original.
Con Kolivas forked that to make cgminer, the CPU/GPU miner.
I joined the cgminer project to add FPGA/ASIC support.
When GPU mining died, Con and Kano forked the collaborative project into the present-day cgminer (he retained the name/repository), and later rewrote FPGA/ASIC support (as well as removed CPU/GPU support).
I have continued to maintain and improve the original CPU/GPU/FPGA/ASIC project under the name BFGMiner.

I'm not planning to fork the Bitmain code, but rather to reverse engineer it and write a new userspace-only driver.
So far I've just been studying how it interfaces to the hardware - mainly the kernel code so far.
Perhaps it's best if you start at the userspace/cgminer side so we don't overlap?
I'm about to be AFK for a bit, but maybe later we can discuss further on IRC