Adjusting for “excess grandparents” as described above seems to have potential in alleviating the topology problem (“latency inequality”). The idea is that high-latency miners will disproportionally reference a parent that is a grandparent of a low-latency sibling. I did some data collection and noticed these “grandparents” occur equally as often as 3 parents when my target is parents = 1.44 and when the latencies are evenly distributed. The grandparent to 3-parent frequency ratio is normally 1:1 and it increases when latency is higher for some of the miners.
To clarify, I want to identify blocks that have a parent that would have been a grandparent if not for the block having excessive latency in receiving the parent and/or sending out his own block that’s a child to it. I’m calling them a grandparent, but they’re a parent. I adjust the DAA for the child block. He’ll get very slightly higher difficulty for having longer latency and thereby having this type of parent, and his descendants will feel the small effect. We assume >50% honest miners who won’t steal pennies to lose pounds.
Data collection to see if it would have the effect I thought it would
naughty grandparents per 3-parents
hashrate fraction v. multiples of latency increase
HRF 2x 4x 8x
0% 102% 102% 102%
1.25% 108% 111% 100%
2.5% 111% 121% 94%
5% 117% 134% 93%
10% 131% 169% 126%
20% 147% 195% 215%
30% 140% 192% 229%
40% 133% 179% 206%
50% 124% 153% 188%
60% 117% 138% 174%
70% 116% 127% 169%
80% 108% 120% 165%
90% 107% 117% 159%
95% 149%
100% 102% 102% 102%
Since the ratio is 1.02 during equitable latency conditions, a simple change to the difficulty algorithm could be used. The existing difficulty was:
D = avgD * (1 + (numParentsObserved - 1.44) / 200 )
so I added:
D = D * (1+ (grandparents - 3parentsBoolean) / 200 )
avgD is the average difficulty of the block’s immediate parents. 3parents is either 1 or 0 depending on if there were 3 parents for that block or not. It could be more sophisticated. These type of gandparents can be more than 1 for a block.
It worked as good as the original equation under normal stable conditions and during hashrate attacks without change.
These two charts show it reduced the problems caused by 20% of the miners having up to 4x slower latency.
A comparison to 1 or 2 parents has more data and thereby be more accurate. 2 parents gave the best result. An adjustment to the 2nd equation is needed due to 2 parents being 4.4x more common than ‘grandparents’ under homogenous latencies. To clarify “hogobenous”: latencies can vary widely and randomly and everything works fine for all algos as long as the latency is homogenous among all miners. The grandparent adjustment has a beneficial effect when they aren’t
D = D * ( 1 + (grandparents - 2parentsBoolean/4.4) / 200)
It doesn’t work as good if the hashrate fraction is 15% instead of 20%. It would be good to provide protection when only 5% of miners have excessive latency, but that seems too challenging.
The next 2 charts show the benefit is more pronounced when 25% of the hashrate has high latency. The 1st one with the higher difficulty is with the new equation above.
