OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30

[Kurvanga]

How can I fix that? pool does not see any work of course.

Code:

 
 [2014-11-02 11:42:21] HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl

Try updating libcurl (if you're using Linux).  Definitely try:

sudo apt-get install build-essential autoconf automake libtool pkg-config libcurl4-gnutls-dev libjansson-dev uthash-dev libncursesw5-dev libudev-dev libusb-1.0-0-dev   libevent-dev libmicrohttpd-dev hidapi

sudo apt-get update
sudo apt-get upgrade

You may also have to rerun ./configure and make again...

His libcurl is fine. No version of libcurl supports stratum+tcp, so this is an ordinary message before it uses its own implementation.

Also, I don't see any actual problems in his log...

Thanks for the reply guys

Apart from that there is zero activity on the pool from my worker when i'm using BfgMiner same for the bfgminer output. I can post it if needed when i'm at home.

ltc.com is dead...just visited the website and it's just junk...so, probably try multipool.us (anything scrypt also mines doge) or liteguardian.com if you only want to mine litecoin...

Hehe the poll address is fake just intentionally, ok so I downloaded 4.10 ver for my windows machine and it acts the same when i'm trying to mine with my gpu, bfgminer-3.10.7-win64 works fine with the pool i use  , bfgminer-4.10.0-win64 does not. The same issue is on linux. May it be a pool is incompatible? I am mining there with dmaxl's cgminer but it's not updated anymore.

[1714776214]

1714776214

[1714776214]

1714776214

[Luke-Jr]

Hehe the poll address is fake just intentionally, ok so I downloaded 4.10 ver for my windows machine and it acts the same when i'm trying to mine with my gpu, bfgminer-3.10.7-win64 works fine with the pool i use  , bfgminer-4.10.0-win64 does not. The same issue is on linux. May it be a pool is incompatible? I am mining there with dmaxl's cgminer but it's not updated anymore.

Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression.
1. Enter anything random for Session name, click Go.
2. For "Working commit:", put bfgminer-3.10.7
3. For "Broken commit:", put bfgminer-4.10.0
4. Click "Start"
5. Wait for the webserver to build a CUSTOM version of BFGMiner (ignore the version it claims to be when you run it).
6. Download the custom build, and test if it works. Click the relevant button.
7. Go back to step 5 until it gives you a "verdict" on which change is guilty for breaking it.
8. Post the final result here.

[Elmit]

Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression.

sh: ./make-release: No such file or directory

[Luke-Jr]

Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression.

sh: ./make-release: No such file or directory

I don't know what you're trying to say. It's expected that some builds throughout this process will fail, and it should automatically move on...

[Elmit]

Creating a new session:
Session name:  Ronald
Working commit:  bfgminer-3.99.0
Broken commit:  bfgminer-4.10.0

[Start]

-----------------------------

On commit c4c06166a2ab6937d2d6e198842289ca83c67770
c4c06166a2ab6937d2d6e198842289ca83c67770 build failure (http://luke.dashjr.org/tmp/code/webisect/wr/c4c06166a2ab6937d2d6e198842289ca83c67770.log) - skipping

[Luke-Jr]

Creating a new session:
Session name:  Ronald
Working commit:  bfgminer-3.99.0
Broken commit:  bfgminer-4.10.0

[Start]

-----------------------------

On commit c4c06166a2ab6937d2d6e198842289ca83c67770
c4c06166a2ab6937d2d6e198842289ca83c67770 build failure (http://luke.dashjr.org/tmp/code/webisect/wr/c4c06166a2ab6937d2d6e198842289ca83c67770.log) - skipping

So wait for the next build...

[AJinNYC]

How would I overclock more than one ASIC unit? I'm using MultiMiner, but I believe that just sits on top of BFGMiner as a GUI.

I got 8 Antminer U2s and one CryptoRig Hitchhiker NanoFury. I can overclock the NanoFury without an issue, but when I try to overclock the Antminers, in addition to the NanoFury, I get the same performace out of the Antminers as I do when I don't overclock them. What's the proper syntax to use when trying to target more than one device?

[nwoolls]

How would I overclock more than one ASIC unit? I'm using MultiMiner, but I believe that just sits on top of BFGMiner as a GUI.

I got 8 Antminer U2s and one CryptoRig Hitchhiker NanoFury. I can overclock the NanoFury without an issue, but when I try to overclock the Antminers, in addition to the NanoFury, I get the same performace out of the Antminers as I do when I don't overclock them. What's the proper syntax to use when trying to target more than one device?

e.g.:

Code:

--set amu:clock=x0881 --set nfy:osc6_bits=53

[chup]

@nwoolls
Could you please update the WR703n firmware to BFGminer4.8. I cannot do it myself, got stuck on the size of the firmware.
Thanks

bfgminer-ar71xx-generic-tl-wr703n-v4.10.0-r1-squashfs-factory.bin
bfgminer-ar71xx-generic-tl-wr703n-v4.10.0-r1-squashfs-sysupgrade.bin

Sorry for the delay.

Should this image work on TL-MR3020 3G? (Atheros AR9330 rev.1, 4MB flash and 32MB RAM)? Thx.

[Luke-Jr]

So after a ton of work, multi-blockchain and multi-algo support for BFGMiner is starting to shape up.
I would greatly appreciate if others interested in this field could contribute by testing and/or improving documentation as needed to make usage of new features easily accessible.
"Multipool" operators are asked to review the new stratum extension proposals to ensure they cover all desired use cases and/or help test them.
Front-end developers (or anyone using RPC) likewise are welcome to critique the RPC changes.
If anyone wants to get their favourite proof-of-work algorithm added for 5.0, now is the time to propose your code in a merge/pull request (sorry, I don't have time to write this code myself at the moment, so you'll need to bring-your-own-code).

DRAFT Human readable changelog:

• Multi-blockchain support: BFGMiner can now be told which pools use the same "mining goals", and will track the blockchain independently for ones that don't. This allows you to mine multiple cryptocurrencies concurrently using any pool strategy (including balance and load-balance).
• Multi-algorithm support: BFGMiner is now capable of hashing on both scrypt and SHA256d work at the same time, and you can assign the mining algorithm to use on a per-goal basis. As with multi-blockchain support, this works even in balancing strategies. Note that at this time, only CPU, OpenCL, and Proxy drivers actually support multiple algorithms at the same time (DualMiner must be preconfigured for only one, and GridSeed remains scrypt-only).
• Stratum extensions for mining goals: New experimental methods mining.capabilities and mining.set_goal for Stratum allow you to expose control of the mining algorithm to the pool. These extensions are considered draft and may be changed based on the needs of multiblockchain pool operators.
• RPC: Also extended for multiple mining goals/algorithms. Interface is subject to change.
• Titan: Work flushing optimisations from KnCMiner.

The code is in git under the bfgminer branch (and tagged bfgminer-4.99.0).
Windows downloads are available from http://luke.dashjr.org/programs/bitcoin/files/bfgminer/4.99.0/

[damm315er]

Is supporting neoscrypt in BFGminer's future?

[Luke-Jr]

Is supporting neoscrypt in BFGminer's future?

If someone contributes the code...

[nicehashdev]

Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.

BTW; as soon as you prepare BFG version with these features, we are ready to update our stratum proxy @ NiceHash to support this and give it a try.

[Luke-Jr]

Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.

Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...

Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.

Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point

[nicehashdev]

Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.

Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...

Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.

Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point

As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together. Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm".

Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already.

[Luke-Jr]

Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.

Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...

Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.

Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point

As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together.

So maybe:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}})

Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm".

Well, that wouldn't work. Most of the time (at least right now, all of the time), cost and performance are unknowns - so BFGMiner has nothing to send for those.
In practice, I was thinking of sending:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":[],"SHA256d":[]}})

Another thing maybe we need to consider is how you would want to handle rigs that have a set of scrypt+SHA256d devices (CPU, OpenCL, maybe DualMiner in the future), and also SHA256d-only devices...

Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already.

Yes, this is already the case.

[Mario241077]

Please add neoscrypt as soon as possible

[7000pool]

i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools 
only work with the first pool & discard the rest 

[Luke-Jr]

i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools 
only work with the first pool & discard the rest 

Are the pools working on the same blockchain?
If not, are you using 4.99.0 and giving the pools separate goals?

[7000pool]

i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools  
only work with the first pool & discard the rest  

Are the pools working on the same blockchain?
If not, are you using 4.99.0 and giving the pools separate goals?

same pool & blockchain with different login/worker only
using 4.10.0