What a load a horseshite, pardon my french ... you continue to be totally vague, despite repeated requests for actual details and explanations. You must think we're all stupid. Let's see:
The first communication checks the update and receives license information, including for example where to mine devfee. Because of security reasons, it would be very hard to eliminate this private communication.
Total BS. If that were true, all miners would require it. What security concerns? Explain it to the experts. I'm a dev myself. Let's hear it.
The follow-up communications only send runtime information of bminer, like the mining speed of each card and performance status. This may enable bminer to choose better optimization strategies.
Complete BS. You don't need to call back home to enable optimizations. Build them into the executable like any sane developer.
I understand your concerns about the private connection. In future, I will consider making the follow-up runtime communications transparent. Or alternatively, I can create an option to opt-out the communications.
Remove it. Can't you see it's the biggest reason why people hate you and your miner?
Right now it all screams that you are shady. Sorry, but the repeated times you were called out on this and failed to provide details to reassure users all point to hidden interests.
@EVERYONE: I'm nearing completion of the stratum proxy for equihash (and other algos) which allows you to see the actual hashrate accurately, computed from the submitted shares to the pool -- no need to rely on the pool or the mining software, both of which can rip you off by under/over-reporting. Currently I've hit a problem with bminer and I'm working on a workaround until @realbminer fixes it (below).
Preliminary results so far show that bminer is not faster than dstm, but you will all be able to test them yourselves in a controlled environment, finally.
@realbminer: you are using the same seed for the nonce every time a new job is sent by the pool ... this is bad programming. When multiple rigs running bminer are connected to a proxy, they all receive the same job (proxy broadcasts it). Normally, each rig should start with a random seed, and hence find different solutions below the target. However, bminer always starts with the same seed, and the rigs find the same solution, they all submit it, the pool accepts only the first one and rejects all the others, and then bminer finally craps out with "too many invalid solutions".
You really need to fix this. Please also add an option to configure the number of invalid shares before restarting ... you have too many hard coded parameters.
Below is a merged log from 13 miners connected via the proxy:
m3 1 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 5 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 3 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 8 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 9 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 6 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 11 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 2 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 0 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 7 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 10 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 12 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 4 [INFO] [2018-02-15T07:35:32+02:00] Received new job db87
m3 6 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 1 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 11 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 3 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 8 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 2 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 10 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 0 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 9 [INFO] [2018-02-15T07:35:35+02:00] Accepted share #8
m3 5 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 7 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 12 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 4 [WARN] [2018-02-15T07:35:35+02:00] Rejected share #8 ([22,"duplicate share"])
m3 6 [WARN] [2018-02-15T07:35:37+02:00] Rejected share #9 ([20,"invalid solution"])
m3 6 [INFO] [2018-02-15T07:35:50+02:00] Accepted share #10
m3 1 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 10 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 10 [WARN] [2018-02-15T07:35:51+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 0 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 11 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 9 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 11 [WARN] [2018-02-15T07:35:51+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 3 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 3 [WARN] [2018-02-15T07:35:51+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 2 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 2 [WARN] [2018-02-15T07:35:51+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 8 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 8 [WARN] [2018-02-15T07:35:51+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 5 [WARN] [2018-02-15T07:35:51+02:00] Rejected share #9 ([22,"duplicate share"])
m3 5 [WARN] [2018-02-15T07:35:51+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 12 [WARN] [2018-02-15T07:35:52+02:00] Rejected share #9 ([22,"duplicate share"])
m3 12 [WARN] [2018-02-15T07:35:52+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 7 [WARN] [2018-02-15T07:35:52+02:00] Rejected share #9 ([22,"duplicate share"])
m3 7 [WARN] [2018-02-15T07:35:52+02:00] Get error: Too many rejected shares, resetting in 5 seconds
m3 4 [WARN] [2018-02-15T07:35:53+02:00] Rejected share #9 ([22,"duplicate share"])
m3 4 [WARN] [2018-02-15T07:35:53+02:00] Get error: Too many rejected shares, resetting in 5 seconds
p.s. For any experts out there, including @realbminer: No, the proxy should not relay all messages in order to get different jobs for different rigs. A true proxy should be able to act like a single miner, the pool sending only one job, then the proxy broadcasts to all rigs and merges replies from rigs to the pool. The purpose is reduce communication overhead from the pool and hence also reduce likelihood of stale shares.