Topic: [ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9 - page 122. (Read 148347 times)
February 15, 2018, 08:57:03 AM
Thanks for your hard work on investigating, guys. I'll stay away from Bminer for now.
February 15, 2018, 04:00:34 AM
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?
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?
February 15, 2018, 01:10:12 AM
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.
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.
February 15, 2018, 12:53:42 AM
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:
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.
Complete BS. You don't need to call back home to enable optimizations. Build them into the executable like any sane developer.
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.
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://[email protected]: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
February 15, 2018, 12:43:29 AM
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:
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.
Complete BS. You don't need to call back home to enable optimizations. Build them into the executable like any sane developer.
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:
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.
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.
February 14, 2018, 11:51:08 PM
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.
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.
February 14, 2018, 09:50:38 PM
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.
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.
February 14, 2018, 06:41:03 PM
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.
February 14, 2018, 06:00:01 PM
Why this miner always rebooting my rig w/o any reason? DTSM/EWBF working rockstable 24/7.
February 14, 2018, 05:25:19 PM
Does it have awesome miner support?
February 14, 2018, 03:26:48 PM
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
February 14, 2018, 02:37:17 PM
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?
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?
February 14, 2018, 12:45:10 PM
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.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!
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".
February 14, 2018, 12:36:22 PM
Quote
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.I'm pretty sure if you do that, so many people will undoubtedly dump other miners and jump in instantly. Smiley
Just a thought.
So there will be still a private connection ongoing.
Quote
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.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.
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!
February 14, 2018, 12:24:50 PM
Quote
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.I'm pretty sure if you do that, so many people will undoubtedly dump other miners and jump in instantly. Smiley
Just a thought.
So there will be still a private connection ongoing.
Quote
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.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.
Just think about it.
February 14, 2018, 12:08:29 PM
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.
In my opinion : that actually, should be the number one priority in your plan and schedule.
I'm pretty sure if you do that, so many people will undoubtedly dump other miners and jump in instantly.
Just a thought.
February 14, 2018, 11:57:23 AM
Ok, this is fu**ing ridiculous ... you need to remove that shady private connection to your website:
Your server went down and the miner stopped mining. This is seriously not cool. Besides being shady AF, you are also costing us money. My miners just wasted 1h ...
Code:
[WARN] [2018-02-13T05:13:02Z] Failed to read from the network: Get : dial tcp: lookup api.bminer.me on 192.168.1.1:53: read udp 192.168.1.22:42393->192.168.1.1:53: i/o timeout
Your server went down and the miner stopped mining. This is seriously not cool. Besides being shady AF, you are also costing us money. My miners just wasted 1h ...
This communication is not the root cause of the mining hang. Mining should continue even if you cannot connect to api.bminer.me. It is very likely caused by the reconnection issue that is already fixed in 5.4.0. Could you try 5.4.0?
February 14, 2018, 11:24:47 AM
From a week ago my rigs begin spam this:
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
About 10 times and than start the miner. This is not the first question on this topic about this bug, but I did not find any answers.
ATTENTION! How to fix this? How to stop this spamshit?
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
[INFO] [time-date] Checking updates
[WARN] [time-date] Failed to read from network: Get : net/http: request canceled while waiting for connection (Client.Timeout exceed while awating headers)
About 10 times and than start the miner. This is not the first question on this topic about this bug, but I did not find any answers.
ATTENTION! How to fix this? How to stop this spamshit?
You may want to add bminer as exceptions in your firewall/defender.
February 14, 2018, 11:22:08 AM
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.
February 14, 2018, 08:29:06 AM
Heh, looks like my last post to this thread was a real hit - must've been my reference to the old Norm Macdonald skit about getting attacked by a weiner dog:
http://www.cc.com/video-clips/4go19i/stand-up-norm-macdonald--fight-your-dog
http://www.cc.com/video-clips/4go19i/stand-up-norm-macdonald--fight-your-dog
Jump to: