04:53:02 <m-relay> <g​ingeropolous:monero.social> might be cool to somehow plot alongside it the difficulty, or difficulty delta of median of something
17:25:20 <m-relay> <m​onero.arbo:matrix.org> 3,469,193 says unknown but belongs to xmrpool.eu https://web.xmrpool.eu/xmr-pool-blocks.html
17:25:41 <m-relay> <m​onero.arbo:matrix.org> I know you said it's rough so maybe you already know it's missing pools
17:26:15 <m-relay> <r​ucknium:monero.social> Hm. Maybe something went down in my data pipeline. Thanks. I will check.
17:27:19 <m-relay> <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
17:27:54 <m-relay> <g​ingeropolous:monero.social> like, "continuous uninterrupted chain" instead of omitted.
17:28:48 <m-relay> <r​ucknium:monero.social> The script for pool data is still running and Hashvault just appeared as the latest block miner
17:29:08 <m-relay> <r​ucknium:monero.social> Ah, yes that's a good term, gingeropolous.
17:30:24 <m-relay> <g​ingeropolous:monero.social> continuous uncontested chain
17:30:31 <m-relay> <g​ingeropolous:monero.social> or continuous chain
17:32:08 <m-relay> <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.
17:48:01 <m-relay> <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" https://arxiv.org/abs/1707.00082
18:07:23 <m-relay> <a​illia:matrix.org> https://arxiv.org/abs/2203.16058
19:31:23 <m-relay> <r​ucknium:monero.social> p2pool mini just orphaned an "unknown" miner's block 💪
19:32:07 <m-relay> <r​ucknium:monero.social> AFAIK, p2pool is designed to promote low-latency propagation of its blocks.
19:33:00 <m-relay> <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.
19:35:44 <sech1> nice
19:36:23 <sech1> I only see this "3469273	p2pool.io | hashvault.pro"
19:36:31 <sech1> it was hashvault's block
19:36:50 <sech1> so it wasn't an unknown block
19:39:44 <m-relay> <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
19:40:36 <m-relay> <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.
19:41:06 <sech1> miningpoolstats registered it
19:41:47 <sech1> but yes, p2pool is more efficient at broadcasting blocks, so it's usually p2pool orphaning other blocks, when there are orphaned blocks