Author

Topic: [ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9 - page 121. (Read 148347 times)

newbie
Activity: 50
Merit: 0
Can someone write a comprehensive post stating what the current red flags are about this bminer?

Recently, a ZCash forum was deleted that showed damning benchmarks that indicated the bminer hashrate log was clearly lying (reporting inflated hashrates, or lying about the dev fee).

Is it still the consensus that Bminer inflates hash-rates, and in actuality is no faster than DSTM?

Have other suspicious things been found about bminer? Sounds like people have found suspicious outgoing network activity from bminer?

There are almost fifty pages of posts about this, and its very difficult given this website's structure to go through them. If someone could write a comprehensive status report about this miner, it would surely make the world a better place.

Currently, all my gpus are running DSTM. If someone has real benchmarks (not console printouts, plebs..) comparing current performance of equihash miners that would be great.

you'll have to start reading the last 15 pages to see what people have been complaining about. theres been several people who have tried to compare dstm and bminer with 24+ hour runs but to be truly accurate you need to run them during the same time period.

most common things you'll see in this thread are:

over reported hashrate...by a lot. most of the reported hashrate on pool side from any benchmark between dstm and bminer are very close. but bminer has 3%+ reported hashrate on the console. on the consoles for the rig i tested it on (6x 1070ti's) i get 3065 sol/s with dstm and 3170 sol/s with bminer. i've let each miner run for 1 week to see how much variance in hashrate i get at flypool and its really a toss up. bminers reported additional 105 sol/s should have some impact on pool side, which it does not seem to. thats obvioiusly not a valid comparison so i haven't posted anything about it, but imo i don't see any effect of bminers higher reported hashrate.

bminer has a private connection that connects to his server for "runtime and licensing information"... hes purposefully avoiding giving us a straight answer on it, and although we've all bitched about it, doesn't seem like he will remove it. its more important to him to have security to get his dev fee than to be upfront about the private connection. no other miners use a private connection like this. theres no reason for anyone to use bminer while it exists especially if theres no true performance gain (not exaggerated hashrates)

there is a bug someone reported that the console is showing that his rig was hashing away just fine but on the pool side there was 0 hashrate. so for whatever reason, lost connection to the pool but somehow was still hashing away.


the perks of bminer are that you aren't giving 2% dev fee to dstm lol.  bminer does seem to be lighter on cpu usage.
newbie
Activity: 4
Merit: 0
Can someone write a comprehensive post stating what the current red flags are about this bminer?

Recently, a ZCash forum was deleted that showed damning benchmarks that indicated the bminer hashrate log was clearly lying (reporting inflated hashrates, or lying about the dev fee).

Is it still the consensus that Bminer inflates hash-rates, and in actuality is no faster than DSTM?

Have other suspicious things been found about bminer? Sounds like people have found suspicious outgoing network activity from bminer?

There are almost fifty pages of posts about this, and its very difficult given this website's structure to go through them. If someone could write a comprehensive status report about this miner, it would surely make the world a better place.

Currently, all my gpus are running DSTM. If someone has real benchmarks (not console printouts, plebs..) comparing current performance of equihash miners that would be great.
newbie
Activity: 1
Merit: 0
Nanopool don't see my email. How to write bat file for nanopool so them see my email and i can change payments. Huh
full member
Activity: 420
Merit: 184
@MagicSmoker, i think you got me confused - I've never mined on zhash.pro

Right you are, as per usual. Someone else suggested trying zhash.pro and you went on a lengthy tirade about zenmine.pro which eerily matches my experience on zhash.pro, hence the likely cause of the mix-up. Besides me not reading carefully and/or remembering every single post I've read eidetically.
member
Activity: 297
Merit: 10
@MagicSmoker, i think you got me confused - I've never mined on zhash.pro
newbie
Activity: 35
Merit: 0
This looks like a proper scam, I suggest everybody to keep away from it unless it will be fixed. Tried it before reading this thread and it looks OK, but unapproved traffic is a definite deal breaker. Kinda obvious, but I will never roll out anything like this to my farm as there is good reliable options out there.

Note to dev: If you are interested gaining users with larger farms, you need to come clean right now. Otherwise good luck with whatever you're trying to pull with your secret data extraction.
full member
Activity: 420
Merit: 184
I can tell you that you should *not* trust the values reported by ccminer-klaust for nvidia (https://github.com/KlausT/ccminer/issues/59#issuecomment-360972071). Excavator is faster for me than ccminer-klaust on nvidia (pool reports and actual payment) ... but this is offtopic, so let's take the discussion about neoscrypt elsewhere.

Slightly more on topic, are you still mining on Zhash.pro or are you back on Flypool? Ever since the server switch on Zhash.pro I have been getting royally screwed on payout (as in - 37% of expected) despite blocks being regularly found, etc. I can understand a pool with this percentage of the network hashrate and a ~1h ttf each block experiencing +/-10% variation in payout on a daily basis, but not -63%.

EDIT - got the usual explanation from the pool op: "we were really unlucky last night, so sorry, no blocks for you!" Funny how they never mention that incorrectly setting their PPLNT or PPLNS variables could be at fault, too.

newbie
Activity: 2
Merit: 0
Can you please add stratum client.reconnect() support to Bminer?

Some pools require it, for example it can't be used on miningrigrentals.com, while other miners (like ewbf) work. I'd much rather use bminer.

Thanks for listening Wink
ETS
newbie
Activity: 24
Merit: 0
I am having an issue my rig takes about 5 minutes for it to start mining with 10 cards with bminer however any other miner it will start within 30 seconds all 10. Also I have the issue of the sol/s starting off extremely low and build up but the build up takes about another 5 minutes until it is at the point were i can tweak the cards if need be i mean anytime the miner has issues or the server connection gets dropped it will take 10 minutes give or take until i am back to mining at full mass is there a reason for that?
@realbminer
member
Activity: 297
Merit: 10
I can tell you that you should *not* trust the values reported by ccminer-klaust for nvidia (https://github.com/KlausT/ccminer/issues/59#issuecomment-360972071). Excavator is faster for me than ccminer-klaust on nvidia (pool reports and actual payment) ... but this is offtopic, so let's take the discussion about neoscrypt elsewhere.
jr. member
Activity: 119
Merit: 3
Excavator has been steadily improving, and it can mine many algos: https://github.com/nicehash/excavator/releases ... it is being developed by some of the known developers that have a track record of developing open source miners (e.g. the ccminer series). I'd love it if they directed more resources for excavator's equihash mining, as lately they focused on other algos (e.g. they really did wonders with neoscrypt; excavator is now one of the fastest neoscrypt miner, on nvidia at least)

Maybe us in here who are obviously looking for good equihash miners could fire some requests and messages of support to the excavator devs

sadly Excavator after nvidia come with cuda 9.1 driver it become unstable like hell, at list on my 1060 is like play rusion rulet it crash random because he exceeds gpu clock what is set in MSI crashing him self & gpu to, i report that to dev but they say they can't reproduce issue with i doubth ... who know my be they will fix in future, i use that miner app a lot & i was like it till he become unrelable coz it was require to monitor him every minute to see when he crash to stop & restart with is unproductive, same other reason i stop use Excavator because dstm & rbminer was release & speed factor Sol/W it was become less efficient ... but i know dev they say they will cach up, atm from what i see they was focus on Neoscript algo ... who know after they will done with Neo they will focus on equihas

p.s. about most fast Neoscrypt my last test done with Excavator vs Hsrminer aka Excavator_v1.4.2a they still was behind Hsrminer (even ccminer done by KlausT was better) on 1060 = ~645 vs ~720, i know atm is 1.4.4.a with i was not tested & hope they made it Smiley
hero member
Activity: 630
Merit: 502
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

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

Put them in ethermine.org.

I'd still support Claymore more than bminer. And I utterly dislike Claymore.
0x1a31d854af240c324435df0a6d2db6ee6dc48bde
0x34faaa028162c4d4e92db6abfa236a8e90ff2fc3
0x3509F7bd9557F8a9b793759b3E3bfA2Cd505ae31
0x368fc687159a3ad3e7348f9a9401fc24143e3116
0x39c6e46623e7a57cf1daac1cc2ba56f26a8d32fd
0x713ad5bd4eedc0de22fbd6a4287fe4111d81439a
0x7fb21ac4cd75d9de3e1c5d11d87bb904c01880fc
0x9f04b72ab29408f1f47473f2635e3a828bb8f69d
0xaf9b0e1a243d18f073885f73dbf8a8a34800d444
0xb4675bc23d68c70a9eb504a7f3baebee85e382e7
0xb9cf2da90bdff1bc014720cc84f5ab99d7974eba
0xc1c427cd8e6b7ee3b5f30c2e1d3f3c5536ec16f5
0xc6F31A79526c641de4E432CB22a88BB577A67eaC
0xde088812a9c5005b0dc8447b37193c9e8b67a1ff
0xe19ffb70e148a76d26698036a9ffd22057967d1b
0xea83425486bad0818919b7b718247739f6840236
member
Activity: 297
Merit: 10
Excavator has been steadily improving, and it can mine many algos: https://github.com/nicehash/excavator/releases ... it is being developed by some of the known developers that have a track record of developing open source miners (e.g. the ccminer series). I'd love it if they directed more resources for excavator's equihash mining, as lately they focused on other algos (e.g. they really did wonders with neoscrypt; excavator is now one of the fastest neoscrypt miner, on nvidia at least)

Maybe us in here who are obviously looking for good equihash miners could fire some requests and messages of support to the excavator devs
jr. member
Activity: 119
Merit: 3
@cryptoyes one thing Claymore it will make more $$$ if his Equihash miner app it will support Nvidia to ... coz it support only AMD Wink personally i will switch gladly to Claymore but i can't coz i use Nvidia Smiley & way because it have most transparent dev fee take implement no shady address, no extra pool permanent connection (it connect only when dev fee is need to be take), evrything is seen
member
Activity: 297
Merit: 10
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.
newbie
Activity: 14
Merit: 0
member
Activity: 297
Merit: 10
@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.
newbie
Activity: 50
Merit: 0
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://[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

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.
jr. member
Activity: 95
Merit: 2
@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.
Jump to: