09:25:10 <sech1> hyc is tevador around at all? RandomX v2 is stuck at like 90% complete since September 2023.
09:28:24 <m-relay> <e​longated:matrix.org> Do we really need this change ?
09:39:00 <sech1> RandomX v1 is soon 6 years old, so yes. It needs to be tuned for modern CPUs.
09:43:41 <sech1> v2 will also bring commitments for fast verification, it's important for nodes https://github.com/tevador/RandomX/pull/265
11:08:04 <m-relay> <t​eoti:matrix.org> Ooh. Will that mean that modern CPUs will see a hashrate increase?
11:08:35 <m-relay> <t​eoti:matrix.org> I like both modern CPUs and hashrate increases, so that would be sweet. :)
13:25:11 <m-relay> <e​longated:matrix.org> Gives an edge to someone with a particular architecture ?
13:40:37 <sech1> 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.
19:58:20 <m-relay> <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)
20:02:21 <m-relay> <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
20:05:55 <DataHoarder> you probably can get the same with https://github.com/tevador/RandomX/pull/265
20:06:07 <DataHoarder> works for nodes, works for share checking
20:06:48 <DataHoarder> I don't think it needs to be xmrig specific here if v2 is in play
20:10:46 <m-relay> <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
20:11:46 <m-relay> <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)
20:25:01 <sech1> XMRig can add "commitment" field, but it will not be the same as v2
20:25:18 <sech1> Remember is that the point of commitment is to calculate the final hash very quickly
20:26:29 <sech1> 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
20:29:31 <sech1> and it will not be the real commitment because the original input is not included
20:29:49 <sech1> so miners can send the same "working" 256 bytes over and over again