Consecutive Block Patterns Don't Match What Hashrate Predicts

[b10c]

Welcome @sorukumar!

@sorukumar

7+ block streaks are 3–7× more frequent than hashrate predicts. Foundry (~24% share average since 2021) has 33 such streaks vs. ~10 expected. 3.17× over. F2Pool has one such event but at 6.69×, sample of one, but that’s not a luck margin

Since Foundry had it’s first 7-block streak at the end of 2022 (2022-11-06), when they were already close to 30% hashrate (and probably had slightly more than 30% hashrate since the beginning of 2023 on average; I haven’t checked in detail), I think it makes sense to do this calculation again with e.g. 30% and 32% hashrate numbers instead of 24%.

See Foundry Hashrate

@sorukumar

Win a block, you’re more likely to win the next one too. P(same pool wins N+1 | just won N) should equal hash share exactly. 1× baseline. SpiderPool runs at 2.70×, SecPool 2.58×, Poolin 2.31×. Upon solving N you already hold the header; everyone else is still propagating.

I was curious how you calculate this for e.g. SpiderPool. The data on your page suggests it’s using data from 2021 till now and are using an average hashrate over that time, but SpilderPool did have highly variable hashrate through this period. I’d assume that for a pool going from 0% to 10% hashrate in two years (and no blocks before) doesn’t produce a usable average? See mempool.space/mining/pool/spiderpool

Might be better to look at shorter timeframe without much variance in hashrate? Or graph the expected and observed “Second Block Uplift” on e.g. a per-month level per pool?