03:40:06 alMalsamo, i don't know that level of detail. this is an overview of the history. https://moneroworld.com/randomx_2yr.html 03:40:36 and yeah, afaik the X3 was the one that targeted v0. 03:40:47 i don't think any of the following were released to the public 03:50:14 but i think the PoWs that monero used that are on that list are cryptonight, cryptonight v7, cryptonight v8, and cryptonight R. 03:52:56 and afaik x3 v0 (cryptonight) would be Monero Classic, then v1 (cryptonight v7) is MoneroV, then v2 (cryptonight v8) doesn't have any "legacy" chains, and neither does v3 (CnR) 03:54:10 so using some kind of logic you might say that, because the legacy chains are still present, there must be some asic for them, so v0 and v1 03:56:45 man, i forgot there were 3. https://1stminingrig.com/a-word-of-warning-about-cryptinight-asic-miners-antminer-x3-baikal-giant-n-pinidea-rr-200/ 04:21:00 Hmm it still shows 6 coins using CryptoNightv8 (actually v2 because I learned v8 refers to Monero blockchain fork, not CryptoNight alogrithm version): https://wheretomine.io/algorithms/cryptonight-v8 04:21:35 and 3 coins on CryptoNight-R (v3): https://wheretomine.io/algorithms/cryptonight-r 04:22:15 I wonder why these coins use those hashing algorithms... did they fork from Monero whilst Monero was using those PoW algorithms (and then never bothered to update?) 04:25:32 i think v8 (v2) and CnR (v3) may not have ASICs, and other projects just started chains using them. Perhaps FPGAs though 04:29:05 AIUI v1 asics were repurposed to v2 04:30:36 they were not very efficient for v3 but may have been used 04:36:29 Hmm that second article links to here https://minecryptonight.net/ but that site is down hehe 04:37:55 nioc: So there *were* CryptoNight v1 ASICs? I thought the known ASICs like Antminer X3 were CryptoNight v0 only. Do you have any links to info about ASICs for v1, and also info about repurposing those same ASICs for v2? 04:40:30 huh. my monerod is stuck after doing some DNS thing 04:41:58 alMalsamo: I am probably confused. Was assuming things from ginger's description 04:41:59 and it just got unstuck 04:42:34 gingeropolous: Thanks for the link on https://moneroworld.com/randomx_2yr.html it seems to have the same dates as the official Monero README.md on Github that fluffypony linked me to with all of the different blockchain forks that Monero has gone through (explaining why people erroneously call the PoW algorithms v7 and v8). But that graph on your page confuses me, why does the historical hashrate 04:42:40 dip SO much once CryptoNight v3 was implemented? I could understand the hashrate dip at the upgrade to v1 because that made the miners for v0 worthless, but why the huge drop when switching to v3? 04:42:51 Also what is the reason the hashrate RISES so much after switching to RandomX? 04:43:15 randomx is just a faster hash 04:44:28 and the v2 to v3 dip means there might have been asics on v2. Also, I think CnR was a bit harder on GPUs... though there are probably tables somewhere with actual hashrate comparisons 04:52:16 gingeropolous: do you know anything about the plethora of OTHER CryptoNight variants listed here: https://wheretomine.io/algorithms/all I am surprised to see that there are so many... 04:53:01 no, not really. once sech1 demonstrated how you could tweak cryptonight, it looks like people had a lot of fun rolling their own versions 07:03:14 Hello again. I had to reboot the raspi that was housing the monerod + p2pool. And after the restart and directing my miner computers back to that raspi, p2pool daemon is showing an inconsisten "Shares Found" statistics. 07:03:46 More specicifally, I had around 8 shares before the reboot, and now, after the reboot, the p2pool daemon is reporting that my shares are in fact 4. 07:03:54 What's up with that? 07:10:05 s/inconsisten/inconsistent/ 09:10:48 For the record, CN-R is v4, not v3, as CNv2 stayed on for 2 forks. 09:11:01 (I just checked the source) 09:11:37 For reference, check src/rpc/core_rpc_server.cpp, look for "witch (variant)" 09:35:44 7 09:35:44 4 09:35:52 damned cat 12:35:20 6 12:35:23 9 12:35:36 damned cat 13:45:01 "More specicifally, I had around..." <- The reboot will reset the counter, and when p2pool is first syncing it will report false shares if clients are mining against it during sync. 13:45:19 p2pool doesn't store the share count outside the running process so all stats get reset if the process is restarted. 13:49:04 > <@sethsimmons[m]:libera.chat> > <@mechanic41turk[m]:libera.chat> More specicifally, I had around 8 shares before the reboot, and now, after the reboot, the p2pool daemon is reporting that my shares are in fact 4. 13:49:04 > 13:49:04 > The reboot will reset the counter, and when p2pool is first syncing it will report false shares if clients are mining against it during sync. 13:49:04 Yeah that must be it.