<g​ingeropolous:monero.social> might be cool to somehow plot alongside it the difficulty, or difficulty delta of median of something

<m​onero.arbo:matrix.org> 3,469,193 says unknown but belongs to xmrpool.eu web.xmrpool.eu/xmr-pool-blocks.html

<m​onero.arbo:matrix.org> I know you said it's rough so maybe you already know it's missing pools

<r​ucknium:monero.social> Hm. Maybe something went down in my data pipeline. Thanks. I will check.

<g​ingeropolous:monero.social> its easy for someone in the know to figure out, but perhaps indicate that the yellow omitted blocks mean that there were no orphans / forks during that time

<g​ingeropolous:monero.social> like, "continuous uninterrupted chain" instead of omitted.

<r​ucknium:monero.social> The script for pool data is still running and Hashvault just appeared as the latest block miner

<r​ucknium:monero.social> Ah, yes that's a good term, gingeropolous.

<g​ingeropolous:monero.social> continuous uncontested chain

<g​ingeropolous:monero.social> or continuous chain

<r​ucknium:monero.social> I see `[xmrpool.eu] Finished: reached height 3469168` in the `monero-blocks` log. It looks like it is missing the latest block mined by them. There was a similar issue with nanopool that DataHoarder plans to debug AFAIK.

<r​ucknium:monero.social> Anyone know of a paper or formula for instantaneous hashrate estimation that is more recent than this? Ozisik, Bissias, & Levine (2017) "Estimation of Miner Hash Rates and Consensus on Blockchains" arxiv.org/abs/1707.00082

<a​illia:matrix.org> arxiv.org/abs/2203.16058

<r​ucknium:monero.social> p2pool mini just orphaned an "unknown" miner's block 💪

<r​ucknium:monero.social> AFAIK, p2pool is designed to promote low-latency propagation of its blocks.

<r​ucknium:monero.social> I'm about to push a fix for the visual bug that happens when an orphan block occurs in the most recent 10 blocks.

nice

I only see this "3469273 p2pool.io | hashvault.pro"

it was hashvault's block

so it wasn't an unknown block

<r​ucknium:monero.social> Ah. Seems like we need to find the problem with unassigned blocks. I put a note about it in the UI

<r​ucknium:monero.social> Or, well that was an orphaned block, so maybe I didn't query the API quickly enough before Hashvault stopped reporting its block, due to it being orphaned.

miningpoolstats registered it

but yes, p2pool is more efficient at broadcasting blocks, so it's usually p2pool orphaning other blocks, when there are orphaned blocks