Quote from: mueslo on August 21, 2013, 11:46:48 AM

I hope what you're trying to say is that p_share(t)=const. and p_block(t)=const., this is correct. But to represent that, your scale would have to go all the way to infinity.

I understand it goes all the way to infinity on the right side of the scale. But for the sake of the visualization, I decided not to represent that. What the visualization really represents is what will happen the vast majority of the times, I suppose. The fact that it can only go to infinity is a negligible effect. In part, because both the block time and share time could go to infinity. If you imagine a bell curve, you are talking about the trailing edge.

Quote from: mueslo on August 21, 2013, 11:46:48 AM

This is your fallacy. Changing difficulty would do nothing about that (in your model). The probability to find a share at each point in time would go up, by the same amount everywhere. By your logic, rejected share percentage should be 100%, since most of the scale is to the right of the found block (found block to infinity), which is infinitely more.

But there is another flaw. In reality, As soon as there's a new block, you will start looking for solutions to the new block (with some delay of course). So there is zero chance of you solving a block after you received the broadcast for the same.

What actually happens when your share is rejected, is that your share was found in the few (milli)seconds before you actually received the new block broadcast. It is only due to the lag in network.

To use a similar visualisation:

x = pool/you searching for block X, s: you find a share
X = block X found/you receive broadcast

Code:

Pool server [xxxxxxxxxxxxxxxxxxxxyyyyyyyyyyyyyyyyyyyy]
Broadcast [-------------------X-------------------]
<--+--> Total network latency (round trip)
You [xxxxxxxxxxxxxxxxxxxxxxxyyyyyyyyyyyyyyyyy]
Broadcast [----------------------X----------------]
Share [-s---s---------------s---------------s-]

Any of your shares that is found within the arrows will be dropped (since your share will arrive at the server after it knew about the block)
So essentially, the percentage of rejected shares should be about: t_latency/t_block.

So actually, lowering share difficulty might have the exact opposite effect to the one you want. If it substantially increases load on the server, latency might go up and therefore rejected shares will also go up.

So the effect i'm talking about and rejected shares are not exactly the same thing. A rejected share happens when you solve a share and submit it after the block is solved but before you hear about the block being solved. This is a problem, but a totally different one, and one that is measured in latency.

What I am talking about is when you are working on a share and you DO hear that the block has been solved. That isn't recorded in rejected shares. It just goes away. Yes on an individual level you might solve the share at at exactly the right time and waste no hashrate. You have to look at the statistical probability, over time, to see that you are wasting it.

It boils down to this... there is an inefficiency in terms of the work you do and how you show your work. If you are always partially though the "statistical" time it takes you to solve a share on average, when a block is solved and you have to start over on a new block, then over time you are wasting that hashpower.

If either your hashrate is better or the diff is lowered, the amount that you will be wasting will be smaller on each block change, because you are more frequently notifying the server of the work you did.

Now, this effect does not impact how the pool does as a whole in terms of finding blocks. Not one bit. It just effects the distribution of the reward - skewing it towards a higher hash rate miners.

There is obviously a drawback to lowering the diff or we would have already done it. That draw back is increased server load. If the server can't handle that many requests and the network becomes a bottleneck than its possible we are worse off for it... But as long as the additional bandwidth is not maxing out any links that wouldn't happen.

Its understandable that H2O doesn't want to lower the diff, because he gains nothing for it and gains extra bandwidth. But as individual miners, towards to bottom of the hashrate scale, there is an unfair skew towards the top.