Zawy used a constant ‘a’ in his simulations but in my simulations and in practice ‘a’ is measured by the average “width” of the DAG: Nb/Nc which is the ratio of beads (share-chain blocks) to the number of total-ordered consensus “cuts” in the graph (aka “cohorts”). @sipa this is exactly a difficulty adjustment based on “blocks not in the main chain”, I’m just using some more graph theory to describe the same concept. If you could dig up that reference (probably related to HoneybadgerBFT?) I’d appreciate it and will credit Andrew.
Zawy’s observation is that if you write the bead time and cohort time in units of ‘a’, (Tb/a and Tc/a) you’re left with a function of only one dimensionless variable axlambda where x is the target and lambda is the hashrate. This gives us a clock-free way to do retargeting by targeting having the most possible graph cuts (global consensus points). This is pretty cool because it eliminates a lot of timewarp and DAA manipulation games.
The doc @harding linked above is a work in progress and doesn’t yet include this observation. You can see my first stab at this there which is MUCH more complicated than targeting either a fixed number of parents or a fixed Nb/Nc (which seems to be equivalent).
As far as not punishing latency, the algorithm will pay miners proportional to their work as long as their latency isn’t excessive. At high latencies the miner is likely to create Bitcoin orphans and reduce the profit of the pool. So we need to incentivize latency all a level similar to bitcoin’s natural orphan rate, but if we further incentivize latency below the natural propagation time of shares, we’re incentivizing geographic centralization. High latency corresponds to large cohorts, and for cohorts over a certain size (probably around 25 beads) I want to sort the beads “farthest” from the highest work path through the cohort, and start dropping the highest latency beads from the payment pool. Bitcoin’s orphan rate is around 1% so rough numbers: a=250ms, so a 25 bead cohort corresponds to 5-6s and corresponds to the orphan rate. This deeply assumes all miners are on planet earth and edge cases exist which will use a minimum allowable latency that corresponds to the size of the earth. We’re not offering a solution for mining on the moon. With 3s additional round trip to the moon, mining on the moon is marginal when considering bitcoin’s orphan rate, but mining in Mars is impossible. This should not incentivize geographic centralization. (On earth)
The above idea is contrary to Zawy’s suggestion to orphan high latency beads, I want to include them but not pay them.