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

[sir_blacks]

@cryptoyes one thing Claymore it will make more $$$ if his Equihash miner app it will support Nvidia to ... coz it support only AMD personally i will switch gladly to Claymore but i can't coz i use Nvidia & 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

[cryptoyes]

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

[NameTaken]

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

[sir_blacks]

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

[cryptoyes]

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.

[ETS]

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

[rwaters]

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

[MagicSmoker]

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.

[Mursu]

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.

[cryptoyes]

@MagicSmoker, i think you got me confused - I've never mined on zhash.pro

[MagicSmoker]

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

[artie_k]

Nanopool don't see my email. How to write bat file for nanopool so them see my email and i can change payments.

[orangesherbet0]

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.

[gettilee]

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.

[wetblanket]

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

Any statum-like protocol requires sending a nonce1, as miners require it; it's their unique pool-designated nonce-space in which to generate solutions and this prevents duplicates at the pool - so yes, zpool must send it:

Code:

{"method": "mining.subscribe", "id": 1, "params": ["test/1.0.1", "", "equihash.mine.zpool.ca", 2142]}
{"id":1,"result":[[["mining.set_target","0001fffe00000000000000000000000000000000000000000000000000000000"],["mining.notify","14b0d7e249321c064e953398291e723b"]],"810092d3"],"error":null}

"810092d3" above is the nonce1. What equihash does NOT send (unlike other stratum-like protocols) is the nonce2_size (usually about 4), which indicates the size of the nonce2 solution the pool is expecting to receive in a "mining.submit" share.

Equihash takes a different approach, internally defining the total nonce size to be 32 bytes long (much bigger than other algos), so the miner (and also any proxy!) can calculate the length of the nonce2 it needs to generate to satisfy a total length of 32. So: 32 - len(nonce1) == <how long the generated nonce2 must be>

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.

I disagree that it's easier done in the miner, but this is mostly a matter of perspective:

• My previous point about not being able to control/patch all miners means that if you take the approach of dictating to miners that they have to change their code to your way of thinking simply means that your proxy will not be compatible with miners that choose not to do so. Patching the code isn't the hard part; it's ensuring all miners do so.
• You certainly CAN patch miners to generate nonce2 values randomly; however given the same nonce1, there is still a small chance two rigs will randomly generate the same nonce2 value. This would still result in a duplicate share. The possibility is admittedly incredibly remote, but the chance is still there.

From a different point of view: a miner cannot control what other miners are doing; only the source of information can do that. In a pool -> miner relationship, the pool fills that role. If a proxy is put in the middle, then the proxy must serve that role for its connected miners.

This is literally the canonical proxy example, which does exactly what I'm saying. I'm not inventing this approach, I'm just describing something that already works and all but guarantees the avoidance of duplicate shares.

[Vann]

Nanopool don't see my email. How to write bat file for nanopool so them see my email and i can change payments.

I was able to get it to work with Nanopool by setting a password instead of an email.

Code:

START bminer.exe -uri stratum://<WALLET>.<WORKERNAME>%2F<PASSWORD>:x@zec-us-east1.nanopool.org:16666

[cryptoyes]

@wetblanket, I missed the nonce1 from zpool - to me it looked like the session_id rather than nonce1. However, appending to the nonce1 and prepending to the nonce2 as you previously explained just doesn't work (and can't work). I tried it. Let's continue this on PM.

p.s. of course it's easier done in the miner, and should be done in the miner. Your points are valid, but they perpetuate the problem! It's the miners who should comply first with good practice, and we should encourage, if not coerce, them to ... it's also easier (1 line of code to randomize the seed, rather than hefty work to work around the problem). For anything involving probabilistic approaches, always randomize seeds; in the case of miners, it's pretty idiotic not to because of exactly this proxy problem and duplicate shares.

[wetblanket]

@wetblanket, I missed the nonce1 from zpool - to me it looked like the session_id rather than nonce1. However, appending to the nonce1 and prepending to the nonce2 as you previously explained just doesn't work (and can't work). I tried it. Let's continue this on PM.

p.s. of course it's easier done in the miner, and should be done in the miner. Your points are valid, but they perpetuate the problem! It's the miners who should comply first with good practice, and we should encourage, if not coerce, them to ... it's also easier (1 line of code to randomize the seed, rather than hefty work to work around the problem). For anything involving probabilistic approaches, always randomize seeds; in the case of miners, it's pretty idiotic not to because of exactly this proxy problem and duplicate shares.

For the purposes of closing off the public convo here, we'll just have to agree to disagree then! We simply have different approaches to the same problem. I see your view on this as idealistic; trying to force miners to do things the way you believe is right (regardless of how much better it is) is unrealistic. I choose to approach it from what I see is a more practical vector. But, as you say: sharerate/hashrate measurement is possible either way, and seems to be the goal for many in here.

As I mentioned, this is a borrowed idea, and pseudo-standard in ALL proxies I came across (that I chose to spend time interpreting code on, that is). More importantly, I've confirmed this this approach works with my proxy with both bminer and dstm.

Will msg via PM now. If anyone else on the thread is interested in talking about stratum protocol, please PM me. Now back to your regularly scheduled bminer banter...

[cryptoyes]

Not idealistic at all. It's the required healthy pressure on developers to adopt recommended practices. It happens all the time in various forms. If it hadn't happened then we'd still be using ADA, Fortran and the likes. Bad practices need to go ... encourage developers to write proper stuff, don't encourage them to stay lazy.

[scarey12]

Nanopool don't see my email. How to write bat file for nanopool so them see my email and i can change payments.

I was able to get it to work with Nanopool by setting a password instead of an email.

Code:

START bminer.exe -uri stratum://<WALLET>.<WORKERNAME>%2F<PASSWORD>:x@zec-us-east1.nanopool.org:16666

I think % is special in windows batch files and I had to double them up.  This is working for me on windows with nanopool:

Code:

bminer.exe -uri stratum://ADDRESS.WORKER%%2FEMAIL%%40EMAIL.DOMAIN@zec-us-east1.nanopool.org:6666 -api 127.0.0.1:1880