hyc is tevador around at all? RandomX v2 is stuck at like 90% complete since September 2023.

<e​longated:matrix.org> Do we really need this change ?

RandomX v1 is soon 6 years old, so yes. It needs to be tuned for modern CPUs.

v2 will also bring commitments for fast verification, it's important for nodes tevador/RandomX #265

<t​eoti:matrix.org> Ooh. Will that mean that modern CPUs will see a hashrate increase?

<t​eoti:matrix.org> I like both modern CPUs and hashrate increases, so that would be sweet. :)

<e​longated:matrix.org> Gives an edge to someone with a particular architecture ?

It will be rather an efficiency increase (more RandomX instructions executed per Joule of energy). Hash size will be tuned to result in approximately the same hashrate, because we don't want even bigger dependency on a fast (low latency) RAM.

<f​ede:xmr.mx> could XMRig's protocol also be modified to allow pools do partial verification on most hashes (for example, check 100% of the shares submit by miners, but only do the full, expensive verification on 25% of them)

<f​ede:xmr.mx> (obviously, share verification would only be applied for "trusted" miners, that are miners that sent at least 100-200 valid shares), to prevent abuse of the system

you probably can get the same with tevador/RandomX #265

works for nodes, works for share checking

I don't think it needs to be xmrig specific here if v2 is in play

<f​ede:xmr.mx> well, if i understand correctly, the miner needs to send the output of randomx_calculate_hash, else the pool cannot do a fast verification of the commitment: knowing the output of randomx_calculate_commitment requires randomx_calculate_hash as input

<f​ede:xmr.mx> the current stratum protocol doesn't have a field for this; it would need an XMRig-side modification (however it's not mandatory, just nice to have for pools, also as a nice DDoS protection)

XMRig can add "commitment" field, but it will not be the same as v2

Remember is that the point of commitment is to calculate the final hash very quickly

In case of RandomX v1, the only way to do it is to send the 256 bytes which are hashed in the final step. That's 8 times more than 32-byte commitment in RandomX v2

and it will not be the real commitment because the original input is not included

so miners can send the same "working" 256 bytes over and over again