Investigate reason for high number of **rejected** mined shares

[bladedoyle]

A fast miner (1080 ti GPU) sees a high number of both rejected and stale shares. ex:
"974 accepted, 44 rejected and 25 stales"

A slow miner (1-core on an i7 cpu) sees far fewer stale shares but still sees many shares rejected due to invalid POW. ex:
"109 accepted, 16 rejected, 0 stale"

We need to understand why the shares are rejected:

• does the miner return invalid pow?
• does the data get corrupted in transit?
• is there some issue with the validation code?
• something else?

---

The grin.log messages associated with rejected shares:

Jun 30 00:25:29.786 DEBG pipe: process_block b67f0bcb at 126038 with 0 inputs, 1 outputs, 1 kernels
Jun 30 00:25:29.787 ERRO pipe: validate_header failed for cuckoo shift size 30
Jun 30 00:25:29.787 INFO Rejected block b67f0bcb at 126038: InvalidPow
Jun 30 00:25:29.789 ERRO (Server ID: StratumServer) Failed to validate solution at height 126038: InvalidPow

[yeastplume]

This appears to be happening just after the attempt_time_per_block timeout expires and the server builds a new block with a new timestamp and nonce. If grin-miner returns a solution for the previous block, it's rejected as invalid (presumably because the nonce it returns doesn't match the new block).

[yeastplume]

No, scratch that.. it seems to be happening every time a solution is returned very quickly after the job is sent out, which is very odd (why should that pow not verify in that case?)

[yeastplume]

This (and potentially some cases of #1216) appear to have been caused by reading the wrong solution from an underlying solution output queue.. so if two solutions are found in rapid succession and one meets difficulty, the next job would read an old solution from the queue. Fixed this within cuckoo-miner and the latest version of grin-miner, so will monitor for a while now to see if this occurs again.

[ignopeverell]

Nice! Thanks for looking.

[bladedoyle]

I think (at least part of) the problem is in the Stratum Server.

The stratum server just uses whatever header a miner submits and attaches that to the "current block". If the stratum server just built a new block, and the miner sends a solution for the previous one, the block wont validate (even if none of the transactions changed the timestamp will).

1. The stratum server will need to version the templates it sends - probably by adding an "id" field to the job template struct.
   AND
2. the stratum server needs to keep a history of the blocks it built in the past for the current chain height so it can accept shares for previous versions of the same block.

[bladedoyle]

I believe this is fully resolved, please re-open if necessary.

[HT-Moh]

Hi
I am having same issue with a version 4.0.0 alpha.1

[quentinlesceller]

You certainly using the wrong mining plugin @HT-Moh

[HT-Moh]

@quentinlesceller Thanks for your response, can you please tell me how to identify which plugin to use?
Spec

• Ubuntu
• VGA compatible controller: Intel Corporation Iris Plus Graphics G7 (rev 07)
• Intel(R) Core(TM) i7-1065G7

The only thing I change on the miner config is uncommenting the line
miner_plugin_dir = "./plugins"
and I have this plugin enabled

[[mining.miner_plugin_config]]
plugin_name = "cuckarood_cpu_compat_29"
[mining.miner_plugin_config.parameters]
nthreads = 4
 

[quentinlesceller]

You have to use Cuckaroom.

[HT-Moh]

Thanks @quentinlesceller
Ok I compiled from source and installed the necessary plugins wasn't straightforward but yes it seems to work but not everything, I am having this error on the logs I am not sure if my configurations are correct can you please check

[quentinlesceller]

Is it with the latest master?

[HT-Moh]

Yes its master
I got this error as well

[quentinlesceller]

Okay the ban is unrelated. I'm fixing the error in the log above. But other than that everything is fine and the error in grin-miner logs are okay (not going to cause any problems).

[HT-Moh]

I can ignore as well the ban, right? one more question the size column in the mining device is always 0 and the graph time column as well is that normal ?

[HT-Moh]

I am getting often Error parsing message, so I tried to debug this and saw that I am getting often a message with value a 10 which cause Error parsing message. can you please check screenshot attached.

[quentinlesceller]

@HT-Moh I believe it’s because of this #3315. The stratum sends an empty message.