I think it would be interesting to analyse this both as a difficulty adjustment for a standalone consensus system (as if bitcoin didn’t exist), and as its intended purpose as a way of coordinating reward sharing for bitcoin mining. I think those scenarios are a bit different – for example some form of 50% attack on the former is probably catastrophic, but the same “50% attack” on the latter as long as its kept at the pool level, even when completely successful, can just be dealt with as “okay you’re not letting us in your pool, so we’ll make our own pool” and be completely fine.
In particular, if you have 10% of bitcoin hashrate in a single data centre, and it all uses a single pool with 1ms latency, and meanwhile 70% of hashrate is distributed evenly around the world at 300ms latency on average, then just having two braidpools that run independently is likely fine for everyone concerned. But if the braid were the thing people were trying to come to consensus on diretly, then a chain/braid split isn’t an acceptable outcome.
0.04% (one every 2500 blocks) seems roughly accurate based on fork.observer’s reports. I think the orphan rate due to network latency estimate is 1-e^{-a/600} so at 0.04% that gives a latency of a \approx 240 milliseconds which seems plausible, presuming the only orphans we actually observe are due to latency.
With the same latency applying to a global braidpool, but an expected block rate of 100 blocks per ten minutes (10% hashrate at 1/1000th of the difficulty), then the expected “orphan” rate is about 4%. Conversely, if you target an expected “orphan” rate of 44%, with 10% hashrate, that means beads are 14,500 times easier than blocks, rather than 1000 times easier?
I think/conjecture the look-back/latency constraints are probably critical for this approach’s ability to come to consensus between subsets of hashrate with very different latency properties – the 200:1 latency ratio I suggested would (I think) make it difficult for the latest beads from the two groups to have sufficiently common ancestry that they get merged; whereas I’d expect a 2:1 latency ratio to be more-or-less fine.
If there’s a latency ratio limit where good behaviour breaks down, I think that would be interesting to understand, even if the result is just “well, we automatically have two distinct braid pools in that case, which each pay their members out fairly from the bitcoin rewards for that pool’s found blocks”.
That sounds a bit exploitable to me (presuming including them means they contribute to the most-work comparison) – if you’ve got a signfiicant portion of hashrate, just artificially declare delay everyone else’s beads by X milliseconds, before you include them in your braid. Every now and then everyone else will have a run of bad luck and your tip will become the best tip, making their work not result in a payout. Perhaps the feasibility of this depends on the relationship between X and when payouts get finalised.