I have a slightly flakey internet connection (no good providers in the area). I can stream at reasonable speeds (Megabits) but there is a certain amount of jitter in the packet latency.
Mining is competitive. Will packet latency (on the order of tens, sometimes hundreds of milliseconds) mean that, if I start mining, other miners are likely to beat me to a block? In other words, how close is the race to mine a block?
I suspect, since a number of confirmations are required for consensus, that random delays (variance on the order of several seconds) on later blocks in competing chains, will render my personal latency insignificant, but I would like to see some hard math confirming this.
(I recall reading on the Ethereum blog some analysis of how network latency establishes lower bounds on block time, but I think this was for overall network latency, not considering one jittery miner amongst others with consistently lower latency.)
Best Answer
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:
With an average block time of 12s:
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).