08:28:35 <cohcho> For some reason hashrate distribution of workers has this shape: https://i.postimg.cc/PJVYLDFH/1.png
08:35:02 <cohcho> fetch directly from miner, not measured by pool *
08:37:50 <hyc> what are the axes of this graph? completely content-free post.
08:38:49 <cohcho> vertical:hashrate, horisontal: id,  0...N,
08:41:38 <sech1> what workers?
08:42:30 <sech1> It'd be nice to have numbers and axis on that graph
08:42:45 <cohcho> I've intentionally removed numbers, can't disclose now
08:42:59 <sech1> at least % difference
08:43:11 <sech1> the fastest worker vs the slowest worker
08:47:23 <sech1> the graph looks like rotated sigmoid function
08:47:59 <cohcho> https://i.postimg.cc/PT5dZggw/1.png
08:48:27 <cohcho> vertical axe shows ratio to the minimum hashrate
08:48:34 <sech1> so maybe you choose axis wrong and it's actually a regular s-curve
08:50:34 <sech1> and horizontal axis is how many workers have this hashrate or less?
08:50:39 <cohcho> no axes corresponds to data, assuming you see numbers *
08:51:06 <sech1> or you just sort workers by hashrate?
08:51:11 <cohcho> no, axes corresponds *
08:51:23 <cohcho> It's no histogram
08:51:44 <cohcho> I don't the name, but it's just sorted rows with workers and plotted as hashrate/id_in_table
08:52:19 <cohcho> yes, i've sorted workers by hashrate
08:53:04 <sech1> so if you just draw a graph with horizontal axis = hashrate, vertical axis = % of workers with this hashrate, it'll be Gaussian distribution
08:53:36 <sech1> nothing out of ordinary I would say
08:54:31 <cohcho> horizontal axis = number from 0 to N, vertical axis = hashrate of i-th worker
08:55:25 <cohcho> hashrate devided by min(all_workers)  *
08:55:48 <cohcho> divided*
09:08:29 <cohcho> Yes it's just normal(Gaussian) distrubtion, when plotted the way you suggested. https://i.postimg.cc/dQdbK3kv/1.png
10:22:47 <hyc> can still tweak RandomX to use a steadily increasing dataset, right?
10:22:58 <hyc> much like ETH's DAG
10:25:51 <sech1> yes, some intermediate RandomX version had growing dataset
10:26:40 <hyc> yes I remember
10:27:21 <hyc> though I wonder if gradual growth is a good idea
10:27:35 <hyc> might be better to just double every 18 months
10:28:17 <hyc> just affects how soon people need to buy more RAM I suppose
10:29:22 <sech1> going above 4 GB will require miner rewrite
10:29:44 <sech1> and probably another hit to performance
10:30:41 <hyc> only using 32bit offsets into dataset?
10:31:17 <sech1> "`ma` and `mx` are the memory registers. Both are 32 bits wide"
10:31:24 <sech1> it's even in specification
10:32:06 <hyc> ah well. so at some point in the future we would need to change that
10:32:16 <sech1> there's not enough x86 registers to make them 64 bit, right now they're both stored in rbp register
10:32:50 <sech1> maybe loop counter (rbx) can be used for this, but then loop counter will have to be on stack
10:32:56 <sech1> so small performance impact
10:33:12 <sech1> but bigger performance impact due to TLB cache trashing at some point
10:33:25 <sech1> 1GB pages will have bigger advantage then
10:33:31 <hyc> true
10:35:06 <sech1> doubling dataset to 4096+64 MB should be easy though
16:56:13 <tevador> doubling the dataset would also require doubling the cache to 512 MB
16:57:39 <hyc> I doubt it's something we need to do today. that would drop hashrates quite a bit though.
16:59:54 <cohcho> I'm ok with both 2GiB/256MiB or 4GiB/512MiB
17:01:25 <moneromooo> This would presumably double the memory requirements for verification mode too ?
17:32:24 <sech1> moneromooo yes, but we don't need to do it at all now, I'm thinking about other coins adopting RandomX
17:34:29 <cohcho> Are there any ideas to mitigate hopes (jumps) of miners between different randomx configurations? except merge mining with the biggest coin (monero, probably)
17:34:48 <sech1> Keeping more than 1 dataset in memory
17:35:00 <sech1> to switch instantly
17:35:22 <sech1> or do you mean how to stop miners from doing it?
17:35:46 <cohcho> I mean tottaly opposite: increase barrier or penalty when miner switch to another randomx variant or make it non-profitable
17:36:35 <cohcho> wownero with 1MH/s of rx/wow looks rather small target to test something interesting
17:37:00 <cohcho> I doubt that it will spend more time on development and this coin will disappear.
17:39:01 <cohcho> I suppose that I won't finish development before this coin disappear. *
17:40:23 <jwinterm> lol as much as almost hope you are right cohcho it seems like it just won't die
17:40:46 <jwinterm> I was kind of thinking merge mining makes more sense and maybe try to push wow that direction
17:41:54 <cohcho> Until something bad happened these many variants helps in randomx adoption probably, so it's good for now.
17:43:21 <sech1> PPLNS pools do this. You can't switch every minute because you typically need to wait a few hours before you get full rewards for each pool block
17:45:14 <cohcho> I've described poorly, I mean "nicehash"-ing or double spending  small coin by small portion of miners from big coin.
17:45:54 <sech1> you can't
17:46:17 <jwinterm> well, can't is a strong word
17:46:25 <sech1> it comes down to "how to make mining startup from scratch harder"
17:46:46 <sech1> if you make dataset generation harder, it'll have implications with verification time
17:47:04 <sech1> plus, dataset can be saved to disk and loaded when needed
17:47:22 <sech1> or it can just stay in memory for all different variants
17:47:44 <cohcho> So, switch to randomx for small coins is a trap and they will die or be ouble spended in future.
17:48:30 <cohcho> (perhaps, it's true for all algos )
17:53:45 <sech1> Nicehash supports only rx/0 variant, but big portion of miners use xmrig there and it can mine whatever algo pool tells it to mine
17:54:01 <sech1> so it can be done even now with Wownero
18:05:16 <cohcho> It (wownero) is already dead for double spending: sum of buy bids is 0.24BTC on two available excanges.
18:08:29 <sech1> tradeogre requires 200 confirmations for wownero deposits
18:08:33 <sech1> it was 51% attacked before
18:08:57 <sech1> and wownero block time is 5 minutes, so 1000 minutes to make a deposit
18:09:48 <cohcho> sech1: you can remine previous 1000 blocks if you have enough power, no need to wait
18:09:54 <cohcho> there are no checkpoints
18:10:05 <cohcho> in monero too, checkpoints added only with official release
18:11:41 <sech1> if checkpoints are added on the fly, it can result in permanent network split
18:12:40 <cohcho> I agree, but this way shicoin owner can protect his user with centralized mechanism of checkpoint broadcasting. It's not good solution for healthy decentraized currency.
18:12:54 <cohcho> his users*
18:12:55 <gingeropolous> but good training wheels
18:13:31 <cohcho> decentralized *
18:16:21 <cohcho> I knew two examples of exchanges that accepted double spended tx without any alerts.
18:17:24 <gingeropolous> <hyc> can still tweak RandomX to use a steadily increasing dataset, right? <<< while i like this idea, im concerned about having it based on a schedule. i'd rather we figure out how to make it dynamic in response to blockchain data
18:18:13 <gingeropolous> the primary reason is the monero dystopia, wherein monero has survived as the post-apocolyptic currency run on scrap hardware... but the protocol eventually renders all hardware useless
18:18:57 <gingeropolous> i.e., imagine a scenario where technological development / manufacturing drops off.... free world commerce stops... etc
18:19:37 <moneromooo> Why would you use monero in such a case, and not actually intrinsically valuable stuff like food ?
18:20:12 <moneromooo> Scrap hardware in a post-apoc[a]lyptic world means you're certain to have long periods of disconnection, partitioning, etc.
18:20:44 <moneromooo> Whatever hw you have will likely be better used for actually useful work than mining currency.
18:21:06 <gingeropolous> i guess our dystopian fantasies differ
18:21:53 <moneromooo> I suppose you could have a fairly benign apocalypse.
18:22:20 <gingeropolous> yeah, perhaps apocalypse is too extreme a word or concept.