<x​fedex:matrix.org> Is it possible for an end-user to buy RISC-V CPUs, build a computer with it, and mine RandomX efficiently?

Yes, IIRC Milk-V Pioneer can be bought. It has SG2042 CPU

<x​fedex:matrix.org> it has 64 cores, 64MB L3 cache, it seems

<x​fedex:matrix.org> not enough for XMR mining? doesn't that require 2MB L3 per core to be efficient?

<x​fedex:matrix.org> 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?

<x​fedex:matrix.org> 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).

Miner can send nicehash support in "extensions" json parameter

SG2042 can mine with 32 threads

<x​fedex:matrix.org> Ok thank you.

<x​fedex:matrix.org> And the "nicehash" in Extensions parameter isn't sent by proxy, correct?

<x​fedex:matrix.org> i am not seeing the extension parameters sent by miner to stratum server...

<x​fedex:matrix.org> paste.debian.net/plainh/aa724191

<x​fedex:matrix.org> this is what my software receives from an xmrig miner request (stripped algos and address for simplicity and privacy)... there is no "extensions" field

<x​fedex:matrix.org> isn't "extensions" only sent in the login response (server to client)? then how can server detect if it should use nicehash?

<x​fedex:matrix.org> 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.

No, it's the miner who sends this extension data to the pool

<x​fedex:matrix.org> "extensions" field is included in the Server-To-Client login response

<x​fedex:matrix.org> {

<x​fedex:matrix.org> "id": 1, "jsonrpc": "2.0", "error": null,

<x​fedex:matrix.org> "result": {

<x​fedex:matrix.org> "id": "...",

<x​fedex:matrix.org> "job": {

<x​fedex:matrix.org> "blob": "...", "job_id": "...", "target": "...", "id": "...", "algo": "..."

<x​fedex:matrix.org> },

<x​fedex:matrix.org> "extensions": ["keepalive", "nicehash"],

<x​fedex:matrix.org> "status": "OK"

<x​fedex:matrix.org> }

<x​fedex:matrix.org> }

<x​fedex:matrix.org> this is the login response packet

<x​fedex:matrix.org> i think "extensions" should be sent by Client Handshake too, not only by Server Response

right

<x​fedex:matrix.org> it's limiting, that the pool cannot know what the miner supports, unless it parses user agent, which requires some maintenance burden

You can assume that everyone supports "nicehash"

<x​fedex:matrix.org> xmrig-proxy doesn't support nicehash?

It does

<x​fedex:matrix.org> 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?

Just switch it to simple mode in config

then it pass the nicehash job to miners

<x​fedex:matrix.org> at that point nicehash is useless

proxy defaults to nicehash mode, so it merges 256 miners into 1 upstream miner

<x​fedex:matrix.org> i know that, but let's suppose this

proxy defaults to nicehash mode, so it merges 256 miners into 1 upstream miner

of course proxy can't do it if it gets nicehash job from the upstream

so you must switch to simple mode

<x​fedex:matrix.org> 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.

<x​fedex:matrix.org> 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

pools just use nicehash mode for everyone connecting, they don't care if it's a proxy or not

<x​fedex:matrix.org> in practice i'm suggesting to add the "extensions" field to Client-To-Server login packet, so that pools can react accordingly

i.e. pools bring the burden of configuration to miners. Pools don't care

<x​fedex:matrix.org> but then if a proxy receives Nicehash job, it cannot reduce pool load, since the same job can only be used by one miner

<x​fedex:matrix.org> aka the proxy will make 1 connection per miner

<x​fedex:matrix.org> correct?

<x​fedex:matrix.org> xmrig-proxy would be useless in that case...

yes

<x​fedex:matrix.org> that's why i am proposing to add an "extensions" field

MoneroOcean runs transparent proxies for people who connect many miners (deducting a fee for this)

But usually pools don't use nicehash jobs, they change extra_nonce for each new miner

<x​fedex:matrix.org> 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

<x​fedex:matrix.org> but i think it's a bad design practice

<x​fedex:matrix.org> hardcoding things isn't optimal

but why do you send nicehash job

change extra_nonce instead

<x​fedex:matrix.org> to save RAM and CPU

<x​fedex:matrix.org> changing extra_nonce requires computation of merkle tree

logN time

you only need to update 1 branch of the tree

p2pool can generate 10k extra_nonces in < 0.01 seconds

<x​fedex:matrix.org> 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 :)