[Ethereum] Ethereum mining but not receiving rewards

Ethereum uses a proof of work algorithm called Ethash which like Bitcoin's proof of work uses a difficulty number to adjust how hard it is to find a block.

In pooled mining, members send a valid proof of work to the pool of the same type, but of lesser difficulty, so that it requires less time on average to generate.

When the pool get's a proof from a member with sufficient difficulty, they can submit it to the network as a valid block. When they get a proof of lower difficulty, they have proof of the member's hash rate and can validate that they are working on the same block as everyone else.

There where discussions of how to prevent this when Ethash was designed, but none where found and it was decided to go ahead anyway, under the assumption that most miners would prefer solo mining given the faster block time.

I think this is a reasonable approximation...

A) Let us first suppose your round trip latency is L ms slower than the network average. We will generalize after.

B) Let average block time is t.

C) The probability of when you find a block during a particular block window is independent of your overall hash rate (so you are just as likely mine a block 5s after the previous block are the same as if you had doubled your hash rate; however, your odds of mining any particular block would double). The expected time delta since the previous block is also t (left as exercise to reader).

D) Simplifying assumption: the rest of the "network" is one non-malicious miner (so, for example, does not selfishly mine and includes your blocks, where applicable).

E) W.L.O.G., assume the difficulty of the network is in equilibrium with the hash rate.

A + C means that you start solving a block L time later than the network. Also, when you submit your block, it takes L time to propagate back to the network. Thus, you have a 2L penalty imposed on the amount of time you have to find a block before the network.

Let us suppose, for a moment, that there is a complete lack of connectivity between you and the network and this is the block you would have found that was accepted if you were connected to the network. Now, you both find a block. The expected time for both you and the network to solve the block is t (B + C). But the probability the network solved the block before your (expected) time of solving the block plus latency can be found using the Poisson distribution. The ratio of the probability of solving the block in t vs. t + 2L gives you your efficiency. So if P(x, t) is the Poisson CDF of random variable X being less than or equal to x with expected value t, then you end up with the following efficiency approximation:

efficiency ≈ P(0, (t + 2L) / t) / (P(1, 1) - P(0, 1))

I verified this approximation by simulation; the simulation results are within a few percent of the theoretical number.

Your odds of finding an uncle is approximately the probability of finding a block during time 2L and before the network finds the maximum uncle age (5+?) blocks (reduced by the odds you find multiple blocks back to back before the network). This is trickier to determine.

With average block time of 17s, you end up with the following efficiencies for round trip latency:

  0ms     100%
100ms     98%
200ms     97%
300ms     96%
400ms     95%
500ms     94%
600ms     93%
700ms     92%
800ms     91%
900ms     89%

With an average block time of 12s:

  0ms     100%
100ms     98%
200ms     96%
300ms     95%
400ms     93%
500ms     92%
600ms     90%
700ms     88%
800ms     87%
900ms     86%

Then you can weight your expected average efficiency by the distribution of latency spikes in your connection.

To answer the part about competing chains, we can then extend this to suppose you are part of a local cluster of nodes that have some % of the network. If you are part of the side that generally forms the majority, then the approximation above is reasonably accurate. However, if you are not, then your chances of having a block included in your local cluster need to be calculated, first (as above), and then multiply by the probability of your local cluster's blocks being included in the oracle consensus by using the same efficiency calculation as above; you would need to know the effective hash rate of your local cluster.

If we make the simplifying assumption that large scale miners (for now, the pools) have 0 latency amongst themselves (an obviously incorrect assumption, but 120ms covers LA to Tokyo and f2pool, in China, is responsible for a sizeable fraction of mining capacity), then you can look at the latency between you and one of the pools. If the average node has 25 peers (Parity's default minimum) and there are ~30k nodes), there is an maximum distance of 3-4 nodes between you and any other node, assuming perfect distribution (but we can assume nodes either span short distances with small lag or large distances with longer lag). There is an advantage for pools to have more peers, so this max distance may be smaller -- and you're really only concerned about pools, anyway. So the total latency to a pool is 3x the average node latency. 200ms in total? From there, you can make the worst-case simplifying assumption those nodes are only relay nodes and do no mining (since all the hash power is concentrated in pools). This means that you should add 200ms to your latencies in the table to get your "local cluster efficiency" and compare that to your node's efficiency.

The ice age should not affect this calculation (except to increase block time and thus increase efficiency).