11:25:18 <DataHoarder> @rucknium:monero.social: some of these api set Valid = 0 for blocks recently mined. My code checks for that and ignores blocks not set "valid" or orphaned
11:25:32 <DataHoarder> I am now mapping that to a new field on CSV
11:26:34 <DataHoarder> so all will be added, but it doesn't mean that they are orphaned or not. note the blocks won't get fetched again so "valid" state won't get cleared, but should be perfectly fine for you
11:29:07 <DataHoarder> pushed changes now
11:29:32 <DataHoarder> https://git.gammaspectra.live/WeebDataHoarder/monero-blocks/commit/07ddb862aed9ed7fef3617e0acac0b592f4e3f10
12:21:08 <m-relay> <r​ucknium:monero.social> DataHoarder: Fantastic. Thank you! I hope the new version will fix the issues.
12:21:35 <m-relay> <r​ucknium:monero.social> Your new version is running now on moneroconsensus.info :)
12:23:56 <sech1> nice, 3469273 orphaned block is correctly attributed to hashvault now
12:30:18 <DataHoarder> would it be possible to keep the elected chain in the same side instead of swapping side to side?
12:30:47 <DataHoarder> the orphans could appear on both sides fine, or one only if there's just one
12:40:24 <m-relay> <r​ucknium:monero.social> I know it doesn't look great. With the current graphing method, if I kept the main chain on one side, it would veer off toward the edge of the plot. They have to alternatiev between left and right (and I had to write some ugly code to accomplish that, after sort of reverse-engineering how the plotting algorithm works).
12:40:55 <m-relay> <r​ucknium:monero.social> It's plotting a tree graph: https://r.igraph.org/reference/layout_as_tree.html#ref-examples
12:41:24 <m-relay> <r​ucknium:monero.social> I will try to improve it once I get to other priorities.
12:42:39 <m-relay> <r​ucknium:monero.social> On the bright side, the plotting algorithm "should" smoothly handle multiple sub-chains on different alt-chains. But, hopefully things don't get that crazy.
12:43:05 <m-relay> <r​ucknium:monero.social> Thanks for the feedback.
12:43:22 <DataHoarder> yeah, multiple chains will look nice :)
12:44:20 <m-relay> <r​ucknium:monero.social> "This mushroom cloud looks very pretty."
12:44:55 <DataHoarder> well before we didn't have googles
12:45:10 <DataHoarder> at least now won't get blinded instantly
12:46:38 <m-relay> <r​ucknium:monero.social> This visualizer could also be useful for the next stressnet. In the last stressnet, we did have many alt-chains because syncing wasn't working properly.
12:47:07 <DataHoarder> I'm just impressed at you running websockets over R of all things
12:48:20 <m-relay> <r​ucknium:monero.social> I don't do any of the websockets stuff manually. It's all Shiny translating my R code into JavaScript and web piping.
12:48:45 <DataHoarder> using a "library" counts :)
12:49:31 <DataHoarder> also note, p2pool will not list orphaned blocks, I don't have an endpoint that lists these currently
12:49:48 <DataHoarder> maybe I should update current one to allow for that
12:51:14 <sech1> I think it would look the best if the current longest chain was always a vertical chain of blocks on the left, and all alternative chains would just branch off to the right
12:51:48 <DataHoarder> yeah that's more or less what I suggested
12:51:50 <sech1> https://p2pool.io/api/pool/blocks lists all blocks found by p2pool, even if they were orphaned later
12:51:58 <sech1> *p2pool main
12:52:01 <sech1> but you get the idea
12:52:03 <DataHoarder> but because the render is a tree, it veers
12:52:39 <DataHoarder> yeah I offer the same endpoint too sech1 https://p2pool.observer/api/pool/blocks
12:52:50 <DataHoarder> but the db query doesn't include those
12:53:10 <DataHoarder> I can update this one freely I guess, and just add an optional parameter for the observer specific one
12:59:32 <DataHoarder> actually, it doesn't have it ready in the table view, but if my query is correct there are 706 orphaned blocks (for any reason) in main
13:03:26 <DataHoarder> too expensive to expose in a query currently as it scans the entire block table
13:04:50 <DataHoarder> mini has 99 orphans tracked
13:05:41 <sech1> 706 blocks out of 60362 p2pool-main blocks so far?
13:05:55 <sech1> 1.17% orphan rate, interesting
13:06:18 <sech1> p2pool is efficient at broadcasting blocks, but it can't help if someone is mining through tor of from Australia, for example
13:07:29 <m-relay> <p​yxmr2025:mozilla.org> Damn it, damn Qubic!I think he's running out of money.
13:14:46 <DataHoarder> sech1: a lot are from when a big miner was behind in monerod blocks and time
13:14:56 <DataHoarder> so they just produced garbage stuff
13:15:03 <sech1> ahhh, and the recent orphan rate?
13:15:12 <DataHoarder> how recent, pick a monero height
13:15:20 <sech1> Like the last 10000 blocks
13:15:30 <sech1> From 3459797 until now
13:15:56 <DataHoarder> 8 orphans
13:16:09 <DataHoarder> there were lemme see
13:16:12 <sech1> out of how many p2pool blocks?
13:16:33 <DataHoarder> 380
13:16:46 <DataHoarder> without including alternates
13:16:54 <sech1> 2%
13:17:24 <DataHoarder> mini one orphan
13:17:24 <sech1> Must be some big miners using tor, or just their rigs are with high ping (botnets?)
13:17:25 <DataHoarder> out of
13:17:34 <DataHoarder> 21
13:17:53 <DataHoarder> hmm
13:17:55 <sech1> worse than I expected
13:18:03 <DataHoarder> too low sample size here
13:18:11 <DataHoarder> I have metrics on miner of the blocks
13:18:31 <DataHoarder> but also when they were broadcasted and from which peer at that time, not in db
13:19:52 <DataHoarder> 4/8 are from a specific miner, sech1 
13:20:11 <DataHoarder> https://p2pool.observer/miner/3
13:20:16 <DataHoarder> miner alias: p2pool
13:20:17 <DataHoarder> :D
13:20:33 <sech1> Not surprising :D
13:21:00 <DataHoarder> here's the 8 https://privatebin.net/?c5f66a24c4a6c8b8#HXWwioSdfks9KaLGDnzaHUP1zeX3o6yuBdoDxmFjGQY9
13:21:36 <DataHoarder> btw, it should be 388
13:21:43 <DataHoarder> I did not include orphans in that number
13:21:54 <DataHoarder> still 2%
19:04:17 <mine> hi
19:07:24 <mine> what is better MONERO ANTMINER X5 - 212 khs or (8 X  Intel Xeon E7-8880 v4 ) on a lenovo x3950 x6 with 512 gb ram
19:07:39 <moneromooo> Xeon.
19:07:47 <moneromooo> Antminer will get you 0.
19:08:10 <moneromooo> It was maybe ok back in the day, but it doesn't mine current monero.
19:08:11 <mine> and is at least 2X the price of lenovo
19:09:00 <moneromooo> It is worth 0 nowadays.
19:09:24 <mine> wow why?
19:09:42 <moneromooo> Because it does *not* mine the current monero PoW algorithm.
19:10:24 <moneromooo> AFAIK it's an old thing that mined some verison of Cryptonight. Modern Monero uses Randomx.
19:11:11 <plowsof> The x5 was a recent thing, for Monero if you can believe it 
19:11:28 <moneromooo> Well, maybe not worth 0, it might be able to mine non monero coins that use that CN variant, I dunno if there are any.
19:11:43 <moneromooo> Oh, am I wrong ?
19:11:58 <moneromooo> My apologies then.
19:12:00 <plowsof> Sech1 shown that the hardware was being 'tested' for 1-2 years before dumping them on the public to buy 
19:12:02 <mine> i dont s any other coin
19:12:59 <plowsof> Iirc there was a hardfork to reduce their efficiency? 
19:13:38 <mine> the guy that sell that is a scammer?
19:14:05 <mine> 2400 euro
19:16:07 <moneromooo> Well, it appears I am confusing it for another earlier "ASIC" so maybe not :)
19:16:35 <mine> MONERO ANTMINER X5 - 212 khs
19:16:56 <mine> this is the ad title
19:17:56 <selsta> moneromooo: from what I remember it's some custom hardware with ARM CPUs
19:18:50 <moneromooo> Which wasn't bricked ?
19:20:30 <mine> the  lenovo x3950  with 8 xeon and 512gb ram is 1000 on ebay
19:20:48 <plowsof> Several risc5 cpus on several boards in a box 
19:21:28 <moneromooo> Well, guess it cant be bricked per se if you can control what software runs on it...
19:25:25 <plowsof> sech1 can clarify -hopefully - iirc the ram setup was such that it could be or was  bricked  / made less efficient than normal cpus but i cant find the details :( 
19:26:21 <mine> the  lenovo x3950  with 8 xeon and 512gb ram is 1000 euro on ebay so much cheaper
19:26:24 <sech1> I don't remember, but I think they used one stick of RAM per CPU
19:29:51 <sech1> 8 GB RAM per CPU, so if we increase dataset size to 8+ GB, they will be bricked. But it's easy to fix for them, of course
19:30:43 <plowsof> Thank you
19:30:59 <mine> how to increase dataset size?
19:34:51 <sech1> you can't
19:35:03 <sech1> dataset size is a constant for the current RandomX algorithm
19:36:50 <mine> compile with new size?
19:37:06 <mine> mine size...
20:12:00 <mine> i havent any link until now that check in depth monero ROI
20:12:10 <mine> return on investiment
20:20:54 <DataHoarder> think of it more of buying monero with power+cpu costs, anonymously