[ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9

[MiningTaken]

In my opinion : that actually, should be the number one priority in your plan and schedule. Smiley
I'm pretty sure if you do that, so many people will undoubtedly dump other miners and jump in instantly. Smiley
Just a thought.

He said that he would add an option to opt out the second part of the communication, not the first part.
So there will be still a private connection ongoing.

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.

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.

I understand that you do that so people cannot disable the dev fee, but we still don't want it. Just live with that, most of us don't want to use your miner if there is ANY kind of encrypted connection ongoing. There are alternatives we can use, so you should focus to gain more popularity instead of making your incomes ultra secure or whatever you want to do. You're going against the people who can provide you your 2%, so just think about it, how many people would mess with some shady no dev fee mods if there is a stable and fast miner available, also secure and virus free, with an active development? I don't think many. So you lose this way more than you would lose if a few morons decide to remove the dev fee. Also you're gaining a bad reputation this way. People are talking already that your miner reports the hashrare higher than it actually is.

Just think about it.

Actually, that's what I mean, buddy!
I just not smart enough to use words to express my thought. )
Hopefully, Realbminer could understand what we meant, and not take it negatively.
Happy mining!

[1714095804]

1714095804

[1714095804]

1714095804

[1714095804]

1714095804

[akuci]

Actually, that's what I mean, buddy!
I just not smart enough to use words to express my thought. )
Hopefully, Realbminer could understand what we meant, and not take it negatively.
Happy mining!

Yup, I didn't want to insult the dev in any way, I just told him the truth. He can accept it, or not. It's his problem.
So I'm not against making some connections with his server, but make it transparent, and add an option to disable it. I will personaly not disable it, but I want to know what is he sending over to his server. And yes, I am more than happy to pay the dev fee if someone is really into making a good product, and I'm paying it to every dev since the begining of my "mining career".

[ETS]

I am just wondering why sometimes that my miner puts the miners out of order.
https://gyazo.com/e8eb241405730a850c43c93a10f00cc4
Also is there a way to name the cards or something other than gpu 0,1,2,3,etc. Just to be able to trouble shoot easier since all of the cards might be the same?
Also have you thought about making a bminer for algo phi1612?

[Yorktown2018]

Find a way to remove this shady and ridiculous private connection. Otherwise, EVERYONE SHOULD STAY AWAY FROM THIS MINER! Your rigs can go down whenever @realbminer wishes, or when his server goes down, etc.
...

Dude are you fucking retarded or what? You keep pissing on BMiner, yet you are still using it. There is something seriously wrong with you. If you dont like it GTFO and use some other miner and stop being such an asshole.

Whoa there, weiner-dog... If people don't make a big deal out of secret, encrypted connections made every 15 minutes by a miner program then what incentive is there for the dev to explain it, much less stop doing it?

Complaints like this are not about being an asshole, rather, it's to encourage a bit more transparency and accountability from the dev.

Frankly, I won't use a miner that does this secret squirrel shit, either, even if it is slightly - and I do mean, /slightly/ - faster than the competition.

So if bminer wants my business then he needs to A) improve stability - if your miner is 3% faster than the competition but it crashes with no outward appearance of doing so it isn't faster anymore; B) stop messaging home base every 15 minutes for "licensing information and updates" - what license, and why check for updates every 15 minutes when they aren't released but every month or so?; C) lower the devfee - I know dstm and ewbf charge 2% and the dev thinks he's entitled to the same, but that's not how capitalism works - when you are a newcomer to a field with entrenched competition you can't expect to immediately charge the same as said competition and thrive.

Very much agree.

+1.  Haven't started using the miner because of the concerns.  Transparency is the keyword here...

i too have stopped using bminer because of these concerns

i switched to dstm

Same here. Sketchy crap and I will not be using it until these "features" are stripped and the dev explains himself

[Bluecheese]

Does it have awesome miner support?

[tox22544]

Why this miner always rebooting my rig w/o any reason? DTSM/EWBF working rockstable 24/7.

[gettilee]

Also keen to use this, but the private connection people are worrying about has me worried too.

I will try to explain more about the private connection here.

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.

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.

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.

not good enough. bminer already over reports hashrate by atleast 3%. we don't want the private connection period. no other miner does this and they have no problems collecting their dev fee.

bminer is getting a shit reputation because of your unwillingness to be transparent. you're losing more money by trying to prevent people from avoiding your fee. people aren't using your miner because of the private connection. 2% dev fee of a 0 hashrate is 0.

[revbones]

There is absolutely no reason for a miner to self-update, and that would be significantly problematic.  In addition to the security risks involved, miners set up their rigs in a custom fashion.  One rig may run faster/cooler with a previous driver but the miner discovered that it runs slower with the latest so they haven't updated it.  Why take a risk getting mining software configured and tuned for a rig when it can download an update and screw all your work. 

It should be super easy to disable that functionality, and saying it would be difficult seems super sketchy.

As far as telemetry goes on statistics with different cards, I find it hard to believe that a relatively new mining software package with a limited API and busted hashrate reporting is sophisticated enough at this stage in development to need to collect telemetry on installations or manage licenses in this way.  It definitely isn't worth a 2% devfee.

I"m a developer myself and I'll stick with proven software rather than run a risk like this.  Anyone else is free to roll the dice on it but I wouldn't risk it.  You're putting something on your rigs that can modify itself apparently and regularly phones home to a private server. 

[chiase]

I've had bminer 5.2 and then 5.3 running 24/7 for weeks and on miningpoolhub the reported hashrate and what's shown on the graph is much lower than what the bminer console reports. Anyone else get this?

A single GTX 1080 reports on average 620 sols/s, but the MPH graph will only show briefly hitting 0.64 once in a 24hr period, with the rest of the time hovering at around 0.5-0.55. I don't get this with ewbf.

[cryptoyes]

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:

Code:

 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.

[tipztek]

What a load a horseshite ... 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.

I've been working really hard to try to expose what's being sent back and forth to his servers, but he's gone to great lengths to protect it. So far, here's what I've found:

This is the communication that occurs as soon as you start the miner (there's also some unprintable characters which I omitted, I believe this is encrypted info that I won't be able to break):
GET https://api.bminer.me/v1/init/zec/520 HTTP/1.1
User-Agent: Go-http-client/1.1
Content-Type: application/octet-stream
Accept-Encoding: gzip
stratum+ssl://t1YmvsEuSkADkoYBqtwRt3aJ31GvZzF45fL.w@zec-eu1.nanopool.org:6633/
-----BEGIN CERTIFICATE-----
MIID/DCCAuagAwIBAgIID+rOSdTGfGcwCwYJKoZIhvcNAQELMIGLMQswCQYDVQQG
EwJVUzEZMBcGA1UEChMQQ2xvdWRGbGFyZSwgSW5jLjE0MDIGA1UECxMrQ2xvdWRG
bGFyZSBPcmlnaW4gU1NMIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEBxMN
U2FuIEZyYW5jaXNjbzETMBEGA1UECBMKQ2FsaWZvcm5pYTAeFw0xNDExMTMyMDM4
NTBaFw0xOTExMTQwMTQzNTBaMIGLMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQQ2xv
dWRGbGFyZSwgSW5jLjE0MDIGA1UECxMrQ2xvdWRGbGFyZSBPcmlnaW4gU1NMIENl
cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzETMBEG
A1UECBMKQ2FsaWZvcm5pYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMBIlWf1KEKR5hbB75OYrAcUXobpD/AxvSYRXr91mbRu+lqE7YbyyRUShQh15lem
ef+umeEtPZoLFLhcLyczJxOhI+siLGDQm/a/UDkWvAXYa5DZ+pHU5ct5nZ8pGzqJ
p8G1Hy5RMVYDXZT9F6EaHjMG0OOffH6Ih25TtgfyyrjXycwDH0u6GXt+G/rywcqz
/9W4Aki3XNQMUHNQAtBLEEIYHMkyTYJxuL2tXO6ID5cCsoWw8meHufTeZW2DyUpl
yP3AHt4149RQSyWZMJ6AyntL9d8Xhfpxd9rJkh9Kge2iV9rQTFuE1rRT5s7OSJcK
xUsklgHcGHYMcNfNMilNHb8CAwEAAaNmMGQwDgYDVR0PAQH/BAQDAgAGMBIGA1Ud
EwEB/wQIMAYBAf8CAQIwHQYDVR0OBBYEFCToU1ddfDRAh6nrlNu64RZ4/CmkMB8G
A1UdIwQYMBaAFCToU1ddfDRAh6nrlNu64RZ4/CmkMAsGCSqGSIb3DQEBCwOCAQEA
cQDBVAoRrhhsGegsSFsv1w8v27zzHKaJNv6ffLGIRvXK8VKKK0gKXh2zQtN9SnaD
gYNe7Pr4C3I8ooYKRJJWLsmEHdGdnYYmj0OJfGrfQf6MLIc/11bQhLepZTxdhFYh
QGgDl6gRmb8aDwk7Q92BPvek5nMzaWlP82ixavvYI+okoSY8pwdcVKobx6rWzMWz
ZEC9M6H3F0dDYE23XcCFIdgNSAmmGyXPBstOe0aAJXwJTxOEPn36VWr0PKIQJy5Y
4o1wpMpqCOIwWc8J9REV/REzN6Z1LXImdUgXIXOwrz56gKUJzPejtBQyIGj0mveX
Fu6q54beR89jDc+oABmOgg==
-----END CERTIFICATE-----

I'm reasonably sure this is Nanopool's cert which he uses explicitly to prevent cert forging and MITM attacks on his devfee.

This is the communication that occurs every 10-15 minutes or so (note the content length is way higher than the content which means im missing stuff, possibly speeds):
POST https://api.bminer.me/v1/stats/zec/520 HTTP/1.1
Host: api.bminer.me
User-Agent: Go-http-client/1.1
Content-Length: 727
Content-Type: application/octet-stream
Accept-Encoding: gzip
Connection: close
Linux*
GenuineIntel
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0

Make your own opinions I guess.

cc. @cryptoyes

[cryptoyes]

He statically linked openssl and most likely hardcoded the private key, stripped symbols and probably compressed & mangled the executable.

The fact he's sending back to him information about your rig without ever mentioning it in the readme/help/announcement would normally land him a hefty legal trial ... that's beyond shady. He even transmits the unique ids of each GPU, how nice.

I'll release my proxy soon (open source) and everyone will be able to test. If this thing is skimming hashrate and is not 5% better than dstm as it reports, then it deserves all the bad publicity it can get. So far that's what I noticed in my tests (note that I have access to multiple hundreds of kSol/s, even 1% there matters).

@tipztek -- if he hasn't hardcoded the private key, then MITM is possible and I will look into it after I'm done with the proxy. Maybe that will give him an incentive to play honestly.

[Andrey09]

Tnx. I will wait your proxy, i can't determine what is best DSTM or Bminer.
I think Bmayner overestimates the values in the console to be considered that he is the best miner.

I would like honest results and that the values in the console coincide with the values on the pool. Minus commission 2%. But now these values do not match, why? This is a lie?

[Eviltoaster]

Thanks for your hard work on investigating, guys. I'll stay away from Bminer for now.

[wetblanket]

@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".

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.

I don't think I'm misunderstanding you, in the case that I am, please correct me...

I've done a fair bit of research into proxies and the stratum protocol - I've been building a multi-coin proxy myself, we should compare notes - my findings are somewhat different than yours.

MANY mining devices/binaries will just start their calculations at zero and increment; I agree that it's somewhat better to 'randomly seed', but it IS perfectly valid to just increment.  You're right, with this type of tactic, in the multi-rig scenario you mention, it's absolutely possible and in fact highly likely to hit duplicate shares early without some sort of intervention.  However, the solution to this isn't in the miner (you cannot control how all past and future mining binaries will do this, after all).

Think about this for a second: the pool assigns each miner connection a unique nonce1 value. This gives each connection a unique 'nonce-space' in which to calculate solutions. If every connection to the pool is a miner, then there won't be any duplicate shares submitted. However, if a connection to the pool is a proxy, it still only receives a single nonce1 value and it has to 'share' that nonce1 value with all miners that connect to it. With this in mind...

The better solution lies in the proxy itself (particularly since you cannot control all miners out here)! If you examine how other proxies handle this, they 'assign' a unique nonce space to each miner connection by assigning one or two (unique) bytes per worker connection. For each miner connection to the proxy, this byte value is appended to the nonce1 value (originally received from the pool); and as you know the miner receives this unique nonce1 in their 'mining.subscribe' stratum request.

So, a proxy needs to send the pool's nonce1 + unique byte value per connection (ie. per rig) on subscription, and when a share is submitted from a rig the proxy needs to prepend the rig's unique byte value to the calculated nonce before sending it on to the pool.

There are caveats to this approach; with a single extra byte, you're limited to 256 miners connecting to that proxy. With 2 bytes extra, you get up to 65536 connections allowed. Most other popular proxies I've examined follow this approach, rather than rely on consensus and a common tactic used in miners.

I have this working, and have confirmed that bminer only supports up to 256 because it's hard-coded to only allow a single extra byte to be appended to the nonce (based on my investigation, I believe this was done to support Nicehash, which is like a proxy).

realbminer, if you're reading, you should really look at allowing another extra byte in the nonce1 length to give miners more flexibility - and more proxy compatibility.

[gettilee]

What a load a horseshite ... 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.

I've been working really hard to try to expose what's being sent back and forth to his servers, but he's gone to great lengths to protect it. So far, here's what I've found:

This is the communication that occurs as soon as you start the miner (there's also some unprintable characters which I omitted, I believe this is encrypted info that I won't be able to break):
GET https://api.bminer.me/v1/init/zec/520 HTTP/1.1
User-Agent: Go-http-client/1.1
Content-Type: application/octet-stream
Accept-Encoding: gzip
stratum+ssl://t1YmvsEuSkADkoYBqtwRt3aJ31GvZzF45fL.w@zec-eu1.nanopool.org:6633/
-----BEGIN CERTIFICATE-----
MIID/DCCAuagAwIBAgIID+rOSdTGfGcwCwYJKoZIhvcNAQELMIGLMQswCQYDVQQG
EwJVUzEZMBcGA1UEChMQQ2xvdWRGbGFyZSwgSW5jLjE0MDIGA1UECxMrQ2xvdWRG
bGFyZSBPcmlnaW4gU1NMIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEBxMN
U2FuIEZyYW5jaXNjbzETMBEGA1UECBMKQ2FsaWZvcm5pYTAeFw0xNDExMTMyMDM4
NTBaFw0xOTExMTQwMTQzNTBaMIGLMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQQ2xv
dWRGbGFyZSwgSW5jLjE0MDIGA1UECxMrQ2xvdWRGbGFyZSBPcmlnaW4gU1NMIENl
cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzETMBEG
A1UECBMKQ2FsaWZvcm5pYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMBIlWf1KEKR5hbB75OYrAcUXobpD/AxvSYRXr91mbRu+lqE7YbyyRUShQh15lem
ef+umeEtPZoLFLhcLyczJxOhI+siLGDQm/a/UDkWvAXYa5DZ+pHU5ct5nZ8pGzqJ
p8G1Hy5RMVYDXZT9F6EaHjMG0OOffH6Ih25TtgfyyrjXycwDH0u6GXt+G/rywcqz
/9W4Aki3XNQMUHNQAtBLEEIYHMkyTYJxuL2tXO6ID5cCsoWw8meHufTeZW2DyUpl
yP3AHt4149RQSyWZMJ6AyntL9d8Xhfpxd9rJkh9Kge2iV9rQTFuE1rRT5s7OSJcK
xUsklgHcGHYMcNfNMilNHb8CAwEAAaNmMGQwDgYDVR0PAQH/BAQDAgAGMBIGA1Ud
EwEB/wQIMAYBAf8CAQIwHQYDVR0OBBYEFCToU1ddfDRAh6nrlNu64RZ4/CmkMB8G
A1UdIwQYMBaAFCToU1ddfDRAh6nrlNu64RZ4/CmkMAsGCSqGSIb3DQEBCwOCAQEA
cQDBVAoRrhhsGegsSFsv1w8v27zzHKaJNv6ffLGIRvXK8VKKK0gKXh2zQtN9SnaD
gYNe7Pr4C3I8ooYKRJJWLsmEHdGdnYYmj0OJfGrfQf6MLIc/11bQhLepZTxdhFYh
QGgDl6gRmb8aDwk7Q92BPvek5nMzaWlP82ixavvYI+okoSY8pwdcVKobx6rWzMWz
ZEC9M6H3F0dDYE23XcCFIdgNSAmmGyXPBstOe0aAJXwJTxOEPn36VWr0PKIQJy5Y
4o1wpMpqCOIwWc8J9REV/REzN6Z1LXImdUgXIXOwrz56gKUJzPejtBQyIGj0mveX
Fu6q54beR89jDc+oABmOgg==
-----END CERTIFICATE-----

I'm reasonably sure this is Nanopool's cert which he uses explicitly to prevent cert forging and MITM attacks on his devfee.

This is the communication that occurs every 10-15 minutes or so (note the content length is way higher than the content which means im missing stuff, possibly speeds):
POST https://api.bminer.me/v1/stats/zec/520 HTTP/1.1
Host: api.bminer.me
User-Agent: Go-http-client/1.1
Content-Length: 727
Content-Type: application/octet-stream
Accept-Encoding: gzip
Connection: close
Linux*
GenuineIntel
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0
GeForce GTX 1080 9GB
(GPU-5bea6e5b-1234-4321-abab-12b7e7a78789
0000:00:00.0

Make your own opinions I guess.

cc. @cryptoyes

a big thank you to both of you for your work on this! really appreciate knowing whats going on in his private connection he keeps avoiding to answer.

that proxy server is a great idea, i'm curious to see how accurate hashrates are between pools and other miners as well. this will be extremely helpful when choosing a miner and a pool.

every time i see a reply from bminer, he looks more and more shady. looking forward to his next reply with actual proof of the bullshit we've been calling him out on for weeks. if he doesn't start being transparent i doubt anyone is going to use his miner after reading all the replies in this thread.

[cryptoyes]

@wetblanket - what you propose is not always feasible (depends on the algo, pool and miner; e.g. dstm rejects it, zpool.ca does not even send a nonce1; i also couldn't make it work like you explained with bminer). It shouldn't be handled in the proxy anyway ... I patched nheqminer with random seeds a long time ago because of the same issue. Also, you hit duplicate shares every single time, since every job is broadcast to all miners at the same time.

The fix is so much easier done in the miner ... just change the start seed.

For the purpose of comparing dstm and bminer it doesn't matter though.

[didouday]

When I download the https://api.bminer.me/v1/init/zec/520 I can see the wallet that is used,

1 BTC a week :

https://zec.nanopool.org/account/t1YmvsEuSkADkoYBqtwRt3aJ31GvZzF45fL/w

Nice ?

[NameTaken]

When I download the https://api.bminer.me/v1/init/zec/520 I can see the wallet that is used,

1 BTC a week :

https://zec.nanopool.org/account/t1YmvsEuSkADkoYBqtwRt3aJ31GvZzF45fL/w

Nice ?

EWBF: https://zcash.flypool.org/miners/t1fJuHWrfcWnYMYyP9VAF96vRnvND2NziMG

DSTM: https://zcash.flypool.org/miners/t1NEpmfunewy9z5TogCvAhCuS3J8VWXoJNv

Claymore is making millions per month.

[cryptoyes]

Make that per week in Claymore's case ... Still, everyone should be happier to add to Claymore's income than bminer's. The fact that bminer is making less constitutes no reason to do all this shady and illegal crap: sending himself private data about your machine and your behavior without so much as letting you know in advance is in fact grounds for a legal case here, and his anonymity won't help him if someone was to file it. He pretty much has the ability to control your mining: during testing my proxy once the bminer rigs went offline when bminer couldn't call home because his server went offline. He/she could increase the fee live or request the contents of your thunderbird folder or your wallets and you wouldn't know ... don't leave anything of value on your mining rigs.

I'm still pushing to see if he/she decides to play honestly.

p.s. *Some* of Claymore's Ethereum addresses only:

0x7Fb21ac4Cd75d9De3E1c5D11D87bB904c01880fc
0xe19fFB70E148A76d26698036A9fFD22057967D1b
0xB9cF2dA90Bdff1BC014720Cc84F5Ab99d7974EbA
0x34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3
0xc6F31A79526c641de4E432CB22a88BB577A67eaC
0xdE088812A9c5005b0dC8447B37193c9e8b67a1fF
0xc1c427cD8E6B7Ee3b5F30c2e1D3f3c5536EC16f5
0x3509F7bd9557F8a9b793759b3E3bfA2Cd505ae31

Put them in ethermine.org. Each doing ~50 Ethereum/week (that's nowadays which is very low, used to be 100+ as recent as November)

That's how much these guys make with the hardware you paid for. Still think 2% of all your profits is reasonable? It's a fucking ripoff.

Support open source / free miners! Make one-time donations to those guys instead!

I'd still support Claymore rather than bminer. And I utterly dislike Claymore.