20:16:06 <m-relay> <r​ucknium:monero.social> Very rough web app visualizing live orphaned blocks/chains and who mined them: https://moneroconsensus.info/
20:16:21 <m-relay> <r​ucknium:monero.social> Source code: https://github.com/Rucknium/xmrconsensus
20:18:06 <m-relay> <r​ucknium:monero.social> Special thanks to DataHoarder for pool data: https://git.gammaspectra.live/WeebDataHoarder/monero-blocks (website out of service at the moment?)
20:19:16 <DataHoarder> btw c3pool doesn't return data on api sometimes
20:19:23 <DataHoarder> but it backfills 9999 blocks when it does
20:19:31 <m-relay> <r​ucknium:monero.social> If Qubic attempts selfish mining and/or deep chain re-orgs, the webapp should show it.
20:19:47 <m-relay> <r​ucknium:monero.social> I think. It's untested.
20:19:49 <DataHoarder> if you are running it regularly, it'll show up at some point
20:20:21 <m-relay> <r​ucknium:monero.social> Great. Even if I specify a low `--height`?
20:20:31 <DataHoarder> yeah, it just returns nothing
20:20:42 <DataHoarder> also - as indicated, if there's previous data in csv for that given pool
20:20:50 <DataHoarder> that value will be used as "lowest" height
20:20:57 <m-relay> <r​ucknium:monero.social> I mean,  a high height
20:20:58 <DataHoarder> I'd recommend you just keep a running csv file
20:21:09 <DataHoarder> yeah, it doesn't matter, even first query fails on c3pool
20:21:22 <DataHoarder> so old data is kept until the refetch occurs
20:22:10 <m-relay> <r​ucknium:monero.social> I have it on a 60-second refresh loop, going back 720 blocks each time just to be sure.
20:22:43 <DataHoarder> on https://api.c3pool.com/pool/blocks?page=0&limit=9999 sometimes I get TLS handshake timeout
20:22:50 <m-relay> <r​ucknium:monero.social> Looks like we just had our first live orphaning!
20:23:17 <m-relay> <r​ucknium:monero.social> Unless the app is broken, which it could be.
20:23:27 <DataHoarder> also - many pools don't report orphans. so you probably need to track the old value on your own :)
20:24:07 <m-relay> <r​ucknium:monero.social> Old value?
20:24:26 <DataHoarder> say, p2pool observer finds A at height H and c3pool finds B at H
20:24:33 <DataHoarder> then B wins
20:24:48 <DataHoarder> A will no longer be reported as block on next fetch
20:25:09 <m-relay> <r​ucknium:monero.social> It looks like I have a visual bug when there is an orphan near chaintip. I will try to fix it soon.
20:25:11 <DataHoarder> so if you track the orphan A data you probably need to look at previous dumps of info to see who owned it
20:25:20 <DataHoarder> it looks good though!
20:25:43 <m-relay> <r​ucknium:monero.social> So, I should refresh the pool data more often, perhaps.
20:25:57 <DataHoarder> eh
20:26:14 <DataHoarder> I'd say less often is fine, but the data will still be not reported
20:26:29 <DataHoarder> it's probably "fine" if you keep previous csv
20:26:40 <DataHoarder> I see you are basically sending a png via websocket, able to add links to the blocks themselves?
20:26:52 <DataHoarder> you can probably expose this as a <svg> which would allow that instead
20:27:08 <DataHoarder> plotting backend probably allows that
20:27:08 <m-relay> <r​ucknium:monero.social> But shouldn't I try to query the API between the time that the pool finds the block and when it is confirmed to be orphaned?
20:27:24 <DataHoarder> your Ip will probably get limited
20:27:54 <m-relay> <r​ucknium:monero.social> Just re-running `monero-blocks` will keep the old data in the CSV, right? Not wipe it?
20:28:00 <DataHoarder> yes
20:28:09 <DataHoarder> it'll load it, run the code, then write it anew
20:28:15 <DataHoarder> with old data + new data
20:28:23 <DataHoarder> tbh, you should only launch this when a block is found
20:28:33 <DataHoarder> I think monerod supports running an external program
20:28:44 <DataHoarder> that way it's event based, as quick as needed
20:29:07 <plowsof> --Block-notify iirc
20:29:16 <DataHoarder> yep!
20:29:33 <DataHoarder> have notification + fallback poll every 5 minutes
20:29:55 <m-relay> <r​ucknium:monero.social> There is the plotly library that outputs javascript. I used it for a few plots here: https://moneronet.info/
20:29:57 <m-relay> <r​ucknium:monero.social> But that's heavier and can be more complicated to implement. The R interface for network graphs in plotly seemed poorly maintained. And I can have more control using base R plots, using `igraph`, which is what it's using now.
20:30:09 <DataHoarder> lemme see
20:30:49 <DataHoarder> always fun learning to read a new language, R :)
20:30:50 <m-relay> <r​ucknium:monero.social> That does make a lot of sense. Using --block-notify.
20:31:31 <DataHoarder> so you are using https://www.rdocumentation.org/packages/graphics/versions/3.6.2/topics/plot right?
20:32:04 <m-relay> <r​ucknium:monero.social> I want to add more plots on hashpower share of the pools and attempted double-spend transactions, but this was the hard part. And no one has this visualization, but https://miningpoolstats.stream/monero has hashpower share.
20:32:31 <m-relay> <r​ucknium:monero.social> AFAIK, that's the "basis", but it is a plot of an igraph object, which is
20:33:15 <m-relay> <r​ucknium:monero.social> https://r.igraph.org/reference/plot.igraph.html
20:33:17 <m-relay> <r​ucknium:monero.social> with more docs https://r.igraph.org/reference/plot.common.html
20:33:32 <DataHoarder> hmm https://github.com/rstudio/shiny/issues/2057
20:33:43 <DataHoarder> seems it can be done but you need to make a custom wrapper for it
20:34:08 <DataHoarder> well it's fine as png
20:36:07 <DataHoarder> i see c3pool working on your graph so seems it's good
20:36:49 <DataHoarder> I think that covers all the major pools in poolstats but if you want any other added, poke :)
20:37:08 <m-relay> <r​ucknium:monero.social> Thanks a lot!
20:47:50 <DataHoarder> also- they might lag a bit behind when reporting their own blocks on their APIs
20:48:03 <DataHoarder> so maybe add 10-15s delay at least before checking on the script
20:48:17 <DataHoarder> make sure it also doesn't run multiple times at the same time :)
20:48:27 <DataHoarder> (only one instance is running)
22:25:15 <DataHoarder> maybe adding a "n (0.00%) orphan blocks in the last 240 blocks" or so could be nice
23:15:35 <m-relay> <r​ucknium:monero.social> Good idea.