11:04:30 Is it possible for an end-user to buy RISC-V CPUs, build a computer with it, and mine RandomX efficiently? 11:47:33 Yes, IIRC Milk-V Pioneer can be bought. It has SG2042 CPU 12:03:00 it has 64 cores, 64MB L3 cache, it seems 12:03:59 not enough for XMR mining? doesn't that require 2MB L3 per core to be efficient? 12:08:34 Another thing that's not really related to Monero PoW. Is it possible to see, from a stratum server side, if miner supports Nicehash without having to look at useragent? 12:08:47 So that pools or proxies can send a Nicehash job to miners that support it (e.g. xmrig) but not to clients that do not support or want it (e.g. xmrig-proxy). 12:18:54 Miner can send nicehash support in "extensions" json parameter 12:19:15 SG2042 can mine with 32 threads 12:46:44 Ok thank you. 12:49:06 And the "nicehash" in Extensions parameter isn't sent by proxy, correct? 12:50:51 i am not seeing the extension parameters sent by miner to stratum server... 12:52:05 https://paste.debian.net/plainh/aa724191 12:53:25 this is what my software receives from an xmrig miner request (stripped algos and address for simplicity and privacy)... there is no "extensions" field 12:53:54 isn't "extensions" only sent in the login response (server to client)? then how can server detect if it should use nicehash? 13:51:14 https://github.com/xmrig/xmrig/blob/master/src/base/net/stratum/Client.cpp#L773 13:51:49 https://xmrig.com/docs/extensions/nicehash 17:45:37 Yes, so the pool cannot know if the miner supports NiceHash. Is this correct? Only the miner can know if the pool is supporting nicehash jobs. 17:46:23 No, it's the miner who sends this extension data to the pool 17:46:25 "extensions" field is included in the Server-To-Client login response 17:46:47 { 17:46:47 "id": 1, "jsonrpc": "2.0", "error": null, 17:46:48 "result": { 17:46:48 "id": "...", 17:46:49 "job": { 17:46:49 "blob": "...", "job_id": "...", "target": "...", "id": "...", "algo": "..." 17:46:50 }, 17:46:50 "extensions": ["keepalive", "nicehash"], 17:46:51 "status": "OK" 17:46:51 } 17:46:52 } 17:46:58 this is the login response packet 17:48:23 i think "extensions" should be sent by Client Handshake too, not only by Server Response 17:48:47 right 17:49:31 it's limiting, that the pool cannot know what the miner supports, unless it parses user agent, which requires some maintenance burden 17:54:29 You can assume that everyone supports "nicehash" 17:59:05 xmrig-proxy doesn't support nicehash? 17:59:33 It does 17:59:35 if i send a Nicehash job to XMRig-proxy, it is not going to be able to reuse it for multiple miners, isn't it? 17:59:49 Just switch it to simple mode in config 17:59:54 then it pass the nicehash job to miners 18:00:01 at that point nicehash is useless 18:00:28 proxy defaults to nicehash mode, so it merges 256 miners into 1 upstream miner 18:00:38 i know that, but let's suppose this 18:00:54 proxy defaults to nicehash mode, so it merges 256 miners into 1 upstream miner 18:01:26 of course proxy can't do it if it gets nicehash job from the upstream 18:01:33 so you must switch to simple mode 18:01:40 Let's suppose there is a pool which wants to save as much CPU and RAM as possible. For doing this, it reuses the same job between many miners. But, it musn't send a Nicehash job to Xmrig-Proxy. 18:02:24 It would be easy to solve this problem if the Client-To-Server login packet included the "extensions" field, like the Server-To-Client login response 18:03:24 pools just use nicehash mode for everyone connecting, they don't care if it's a proxy or not 18:03:26 in practice i'm suggesting to add the "extensions" field to Client-To-Server login packet, so that pools can react accordingly 18:03:54 i.e. pools bring the burden of configuration to miners. Pools don't care 18:04:29 but then if a proxy receives Nicehash job, it cannot reduce pool load, since the same job can only be used by one miner 18:04:49 aka the proxy will make 1 connection per miner 18:04:51 correct? 18:05:29 xmrig-proxy would be useless in that case... 18:06:07 yes 18:06:33 that's why i am proposing to add an "extensions" field 18:07:17 MoneroOcean runs transparent proxies for people who connect many miners (deducting a fee for this) 18:08:09 But usually pools don't use nicehash jobs, they change extra_nonce for each new miner 18:08:28 right now on my pool i am parsing user agent, and if it starts with "XMRig/", sending the nicehash job, otherwise sending non-nicehash job 18:08:30 but i think it's a bad design practice 18:08:43 hardcoding things isn't optimal 18:08:59 but why do you send nicehash job 18:09:03 change extra_nonce instead 18:09:07 to save RAM and CPU 18:09:17 changing extra_nonce requires computation of merkle tree 18:09:25 logN time 18:09:33 you only need to update 1 branch of the tree 18:10:15 p2pool can generate 10k extra_nonces in < 0.01 seconds 18:11:53 i didn't know that, sorry... i'm relying on monerod's get_block_template blocktemplate_blob computation, since i am lazy and that thing is quite complex to implement, especially for many different Monero-based altcoins with different headers :)