Finding a hash that is considered a possible block, is unaffected by the network or even the bitcoind code.
I show anything that comes in from a miner and ckpool hashes to a result that is considered a block, or even within a tiny range close to being a block,
even if it is stale, or even rejected by the bitcoind.
On my KanoDB console screen I also display a message if the diff calculation is within 5% of being a block, but I don't rehash the work data for that diff calculation, I use the value ckpool calculates.
Again, KanoDB will show any possible blocks based on the share's difficulty - be they orphans, stales, rejects, or valid.
Thus there are 3 things that can affect finding a block that I show on the web page, listed in order of most likely to least likely:
1) Luck ... yep the one main uncontrollable aspect of block finding.
There's expected results about how often we should find a block, on average, over a large sample of results, based on the total shares submitted to the pool.
When we go too far outside the expected ranges is when we need to consider there may be other possible causes.
2) Withholding
This is when the source of work processing - a miner or a proxy - doesn't return all shares that it should.
A miner should return any shares that it determines to be better than or equal to the work's difficulty requirements.
The miner or proxy can fail to do this due to either a bug, or a modification to specifically discard shares under set circumstances.
Since the majority of the pool is made up of miners that are known to correctly process work and find blocks, the most likely option here would be someone purposefully withholding blocks.
I have reports that I run to attempt to discover sources that are doing this.
3) ckpool bugs
If the work data sent to a miner is in any way different to the data used to verify the miner's results, then ckpool would not recognise shares that were possible blocks.
The chance of ckpool finding a block in the results, if the work storage was incorrect or corrupt, would simply be the equivalent of a CPU miner finding a block.
However, this would also most likely lead to rejecting many shares that were valid.
Our invalids on the pool are not high, so this isn't very likely.
Since we have had one very high diff block, and a second even higher and still not found, very close together, this suggests that there is most likely a problem.
Unfortunately, it doesn't mean there IS a problem, however it does mean that I need to look outside what I normally check.
The luck results from the large amount of work from NiceHash are very discouraging.
They aren't at the point where I consider it beyond redemption, but they are at the point where I considered it appropriate to remove that from the equation.
Since there's nothing that can be done about 1) and I already run reports to track 2) and have removed the most likely cause of that - my course of action to deal with the current circumstances would be to write my own completely independent code to reprocess all the shares submitted over the past month and, firstly, verify that my new code found the same blocks as before, but also see if it finds any others in the share log that were not reported by ckpool.
OMG BLOCK!
