[RFC] Extended mining statistics - accurate hashrates and rig types

[fireice-uk]

With xmr-stak release proxies and pools will loose the ability to differentiate between cpu, amd and nvidia miners on the same machine. This can cause problems for user interfaces. As such we would like to implement extended statistics mode.

To signal its readiness to accept extended statistics the pool / proxy should add following field to the login reply

{"id" : 0, "jsonrpc" : "2.0", "error" : null, "result" : {"id" : "...", "job" :
 {"blob" : "...", "job_id" : "...", "target" : "..."}, "extensions" : ["backend", "hashcount", "algo", "motd"], "status" : "OK"}}

• extensions is a JSON array type, specifying protocol extensions requested by the server.

If the server specifies motd extension, the miner will store a message of the day from the pool operator for display with the hashrate results, unless disabled in the config. Message of the day needs only to be sent once per miner connection, unless it changes.

The field needs to be hex-encoded and optionally added to the job dictionary (either in the login or job packet) as such:

{"blob" : "...", "job_id" : "...", "target" : "...", "motd" : "596F757220706F6F6C206E6565647320796F7521" }

When the miner submits a result, it will add following fields:

{"method" : "submit", "params" : {"id" : "...", "job_id" : "...", "nonce" : "...", "result" : "...", "backend" : "amd", "hashcount" : 15550, "algo" : "cryptonight" }, "id" : 1}

• backend is a JSON string value, which can be "cpu", "amd" or "nvidia" depending on which backend generated the result

• hashcount is a JSON integer value. This is the total number of hashes that the backend in question has done so far. Please note, this number always increases and is not reset on pool switches or disconnects. To calculate a fairly accurate hashrate estimate from pool code you can divide the difference of two hashcounts by the time between them.

• algo is a JSON string specifying the algorithm used to generate the hash ( currently "cryptonight", "cryptonight-lite" ).

[xmrig]

If you has plans to extend the protocol please also add ability to indicate cryptonight-lite is used, it really headache. I known you happy doesn't support it, but it will very useful.
Thank you.

[psychocrypt]

I aggree with @xmrig. Can we define a mendentory key set and optional keys? If so we can allow to provide much more metrics like, fanspeed, heat ... and the pools can extent there usibility if the miner provide that data. Mendentory keys should be a small set of core informations. If so we should define some usefull optional keys that all miner speak the same language. The optional keys should be not included in this PR to have a small feature PR.

[fireice-uk]

@psychocrypt while I don't think fanspeed and heat will be useful, I like the idea of extensibility. I will amend the login / login reply for the server to pick which extensions should be applied.

@xmrig I agree

[psychocrypt]

@fireice-uk If it is optional the pool can decide if it is useful but we should define metrics that they are compatible between miner.

To my ok to add the algorithm I thought again about it and came to the decision that each pool is only handling one algorithm, in this case is it really useful to add the algorithm? @xmrig Do you have an example where it helps to have the information of the algorithm.

[xmrig]

@psychocrypt Some people try use cryptonight-lite with Monero pools, by mistake mostly, others don't change algo when connect to AEON pools. For pools it not hurt much, shares will be rejected and miner banned.

For proxy it worse, because whole proxy can be banned by pool and no easy way to detect lite algo, currently it can be detected only by hash recalculation. Of course I can add this protocol extension for my case, but if it can be standardized it much better.

[fireice-uk]

@psychocrypt I don't believe a pool should be able to dictate to its users what to do, so that would be a hard no on pool-controlled algo. If a pool / proxy implements the extension, it will be able to easily display a meaningful error to the user, who will be free to either switch algos or pools.

@xmrig Are you happy with the new version?

[xmrig]

@fireice-uk Thank you, looks good.

[fireice-uk]

Implemented in xmr-stak 2.0.0

[fireice-uk]

Addition in xmr-stak 2.3.0

When hashcount extension is enabled, miner will add another field:

• hashcount_total is a JSON integer value. This is the total number of hashes that the miner has done so far. Please note, this number always increases and is not reset on pool switches or disconnects. To calculate a fairly accurate hashrate estimate from pool code you can divide the difference of two hashcounts by the time between them.

[Zenobiomartinez120]

xmrig/build/xmrig -o stratum+tcp://dash.poolbinance.com:443 --threads=8 -u Zenob12.001 a=randomx k --coin monero -a rx/0: –threads