Stale blocks: Checking to see if large pools are delaying the release of blocks

[zawy12]

This is an edited cross-post I made to Delving.

Large pools with faster connections between each other is a weak form of selfish mining. They aren't withholding blocks intentionally to get an extra second of mining, but that's the net effect. They get of 1/600 excess profit from the remaining 20% of the network (0.2 * 1/600 = 0.03% excess profit).

Let "large miners" mean miners with fast propagation speeds, presumably mostly the large pools. I'll pretend they are 80% of the network (hashrate-weighted) and distinct from the rest of the "slow" network with a distinctly slower speed instead of a continuous spectrum.

I'm curious large miners are "accidentally" increasing the delay to the rest of the network, and/or if they're delaying the release of blocks to each other. These actions no net effect on their profits relative to each other, but it extracts rewards and fees from the "slower" miners (let "slow" = miners with longer block propagation delays). If a large miner finds a block, then it's ~1 second before the hashrate-weighted slow miner sees it. Conversely, if a slow miner finds a block then it might be ~1 second before the large-miner network sees it. So large miners have 2 seconds before they need to release a block (even to to each other) to give them a head start on the slow miners. And there's another second before the slow miners can mine on top of that cheat, a total of 3 seconds , so if slow is 20% of the hashrate, they could lose 0.2 * 3 / 600 = 0.1% of the rewards to large miners.

I can look at the stale block rate to determine if someone's cheating:

stale_rate =~ 1 - e^(-Delay/600)

This is the exponential distribution CDF. From an old paper, this value is between the median and mean hash rate-weighted propagation delay.

Stale blocks are occurring 1 per 1277 blocks (see data at the end), or more, in the past 44,000 blocks. They can't be fully counted because only a few servers are looking for them and they can't see what all the mining nodes are producing. There might be 20% more.

Rearranging my equation above and using e^(-x) =~ 1-x for small x, the delay is about 600 * 37 / 44,000 = 504 ms or higher. (1 per 1189 blocks, per 8 days). From an old paper who's reference I've lost) indicated this CDF method is between the median and mean of the hashrate-weighted propagation delay.

Grok tells me header propagation has delays 150 to 500 ms.

My equation is supposed to be a value between the mean and median. If I take a sort of average of what Grok is saying I would expect about 288 ms which is 1 in 2,087 blocks. So I can't rule out the possibility that some large miners are delaying the release of blocks by a second, increasing the average delay.

Estimates of the stale block rate before Fibre (a slower network) were 0.31% which implied a 1.86 s delay which was 1 in 323 blocks.

** Data **
These are the block heights at which stale blocks occurred. The data was read at height 904433 from servers x, y, and z. Server y was not active for half the data.

904416 x
902598 x
901939 xz
901154 xz
901092 xz
900150 xz
899701 xyz
897442 xyz
894657 xyz
894070 yz
893765 y
893402 xyz
888946 xyz
883674 y
883335 zy
883183 xyz
881953 xyz
881780 xyz
878195 y
877991 xy (there were 2 at u )
877770 xyz (there were 2)
875589 yz
874036 xyz
873558 yz
879380 xyz
869945 y
866719 xyz
865699 xyz
865333 x
865079 xyz
864527 xyz
863888 xyz
863731 yz
862068 xyz
859749 xyz

Begin counting stales at 35th block at the end (859749) but don't count it.
904433 - 859749 = 44,684
44,684 / 35 = 1277 blocks per stale block,
z = https://fork.observer/rss/1/forks.xml
x = https://forkmonitor.info/feeds/stale_candidates/btc.rss
y = https://github.com/bitcoin-data/stale-blocks/blob/master/stale-blocks.csv