For some reason hashrate distribution of workers has this shape: i.postimg.cc/PJVYLDFH/1.png

fetch directly from miner, not measured by pool *

what are the axes of this graph? completely content-free post.

vertical:hashrate, horisontal: id, 0...N,

what workers?

It'd be nice to have numbers and axis on that graph

I've intentionally removed numbers, can't disclose now

at least % difference

the fastest worker vs the slowest worker

the graph looks like rotated sigmoid function

vertical axe shows ratio to the minimum hashrate

so maybe you choose axis wrong and it's actually a regular s-curve

and horizontal axis is how many workers have this hashrate or less?

no axes corresponds to data, assuming you see numbers *

or you just sort workers by hashrate?

no, axes corresponds *

It's no histogram

I don't the name, but it's just sorted rows with workers and plotted as hashrate/id_in_table

yes, i've sorted workers by hashrate

so if you just draw a graph with horizontal axis = hashrate, vertical axis = % of workers with this hashrate, it'll be Gaussian distribution

nothing out of ordinary I would say

horizontal axis = number from 0 to N, vertical axis = hashrate of i-th worker

hashrate devided by min(all_workers) *

divided*

Yes it's just normal(Gaussian) distrubtion, when plotted the way you suggested. i.postimg.cc/dQdbK3kv/1.png

can still tweak RandomX to use a steadily increasing dataset, right?

much like ETH's DAG

yes, some intermediate RandomX version had growing dataset

yes I remember

though I wonder if gradual growth is a good idea

might be better to just double every 18 months

just affects how soon people need to buy more RAM I suppose

going above 4 GB will require miner rewrite

and probably another hit to performance

only using 32bit offsets into dataset?

"`ma` and `mx` are the memory registers. Both are 32 bits wide"

it's even in specification

ah well. so at some point in the future we would need to change that

there's not enough x86 registers to make them 64 bit, right now they're both stored in rbp register

maybe loop counter (rbx) can be used for this, but then loop counter will have to be on stack

so small performance impact

but bigger performance impact due to TLB cache trashing at some point

1GB pages will have bigger advantage then

true

doubling dataset to 4096+64 MB should be easy though

doubling the dataset would also require doubling the cache to 512 MB

I doubt it's something we need to do today. that would drop hashrates quite a bit though.

I'm ok with both 2GiB/256MiB or 4GiB/512MiB

This would presumably double the memory requirements for verification mode too ?

moneromooo yes, but we don't need to do it at all now, I'm thinking about other coins adopting RandomX

Are there any ideas to mitigate hopes (jumps) of miners between different randomx configurations? except merge mining with the biggest coin (monero, probably)

Keeping more than 1 dataset in memory

to switch instantly

or do you mean how to stop miners from doing it?

I mean tottaly opposite: increase barrier or penalty when miner switch to another randomx variant or make it non-profitable

wownero with 1MH/s of rx/wow looks rather small target to test something interesting

I doubt that it will spend more time on development and this coin will disappear.

I suppose that I won't finish development before this coin disappear. *

lol as much as almost hope you are right cohcho it seems like it just won't die

I was kind of thinking merge mining makes more sense and maybe try to push wow that direction

Until something bad happened these many variants helps in randomx adoption probably, so it's good for now.

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

I've described poorly, I mean "nicehash"-ing or double spending small coin by small portion of miners from big coin.

you can't

well, can't is a strong word

it comes down to "how to make mining startup from scratch harder"

if you make dataset generation harder, it'll have implications with verification time

plus, dataset can be saved to disk and loaded when needed

or it can just stay in memory for all different variants

So, switch to randomx for small coins is a trap and they will die or be ouble spended in future.

(perhaps, it's true for all algos )

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

so it can be done even now with Wownero

It (wownero) is already dead for double spending: sum of buy bids is 0.24BTC on two available excanges.

tradeogre requires 200 confirmations for wownero deposits

it was 51% attacked before

and wownero block time is 5 minutes, so 1000 minutes to make a deposit

sech1: you can remine previous 1000 blocks if you have enough power, no need to wait

there are no checkpoints

in monero too, checkpoints added only with official release

if checkpoints are added on the fly, it can result in permanent network split

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.

his users*

but good training wheels

decentralized *

I knew two examples of exchanges that accepted double spended tx without any alerts.

<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

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

i.e., imagine a scenario where technological development / manufacturing drops off.... free world commerce stops... etc

Why would you use monero in such a case, and not actually intrinsically valuable stuff like food ?

Scrap hardware in a post-apoc[a]lyptic world means you're certain to have long periods of disconnection, partitioning, etc.

Whatever hw you have will likely be better used for actually useful work than mining currency.

i guess our dystopian fantasies differ

I suppose you could have a fairly benign apocalypse.

yeah, perhaps apocalypse is too extreme a word or concept.