Quote from: BLT_NEVER on January 19, 2018, 05:04:29 PM

Quote from: sailor32 on January 19, 2018, 01:10:02 PM

Quote from: BLT_NEVER on January 19, 2018, 08:27:38 AM

Quote from: optiminer on January 17, 2018, 10:05:45 PM

Quote from: lutsifer on January 17, 2018, 06:21:37 AM

Quote from: optiminer on January 17, 2018, 12:45:53 AM

Quote from: lutsifer on January 16, 2018, 10:06:45 AM

Quote from: optiminer on January 16, 2018, 09:22:04 AM

Quote from: Demarsac on January 16, 2018, 02:03:06 AM

Quote

Here is an example from log files

We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}

ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid

Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?

If the protocol is different it goes right away as an error on the first submit.

I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:

Quote

$ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)

It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.

The pool always get warnings when zcash solution is submited:

Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}

And also there is no hashrate.

Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.

Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.

Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.

The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6

My best guess would be that there is NOMP and zerod validate the block difficulty.

OPTI - genuine curiosity has got the better of me, hope you can straighten me out.

Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:

Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)

Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)

Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.

Best be time to lawyer up!

So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as in shares) was going to the dev sever? Especially considering your very low sample size.

Maybe you should explain it again, I don't see a problem here.

Valid points although I think sample size is irrelevant - the client is consistent in its ping to the devfee server, that server is consistent in its reply. And each reply can be visually correlated with a Got New Work line item in the client. Without having access to the underlying src, it is more than plausible to assume that close to 1/3rd of hashing power is being diverted.

What is more telling since I blocked all comm with devfee - my chart has flattened out a bit while my avg HR has remained near consistent. This is what needs a bigger sample size - I'll report back in 24.

All rigs doing ZER work btw...
I

I don't see how it is plausible to assume that network download bandwidth correlates to diverted hashrate without corresponding upload bandwidth. All it really shows is that optiminer is downloading the data needed to do POW calculations, not that its actually doing them. If however you can prove that the program is uploading shares at a higher than expected rate then you have some evidence. When you blocked comm traffic with the dev server did your hashrate change at all, increase by 33%?