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

[jstefanop]

Hey folks!

I'm bumping this because it's still a problem.  Can someone please give me a hand in fixing this?  Thanks!

I'm having a problem with bfgminer (both the new 4.2.0 version and the 4.1.99 jstefanop fork) with failover for both gridseed and zeus (GAWMiner fury) rigs.  Because it's happening with both versions I'm sure it's something dumb. so I thought I'd seek help here.

What's happening is that failover works going from pool 1 to pool 0 when pool 0 becomes active, but it doesn't work when pool 0 goes dead.  Bfgminer reports that it has switched back to pool 1 but the pool doesn't show any hashrate.  As well, my external monitor (CgminerMonitor version 0.7.0) shows the rig as still connected to pool 0.  Finally, I'm getting the following messages displayed in bfgminer:

Code:

[2014-06-16 19:26:49] Pool 0 slow/down or URL or credentials invalid
[2014-06-16 19:27:02] Network difficulty changed to 792 ( 5.68G)

When it's doing this, it sometimes changes the network difficulty several times, then give the "pool 0 slow/down" message again, but it's not accepting shares.

Here's how I'm running bfgminer for the furys:

/root/bfgminer/bfgminer --scrypt -S zeus:/dev/ttyUSB0 --nocheck-golden --chips-count 6 --ltc-clk 328 --config=/opt/cgminer/cgminer_conf/cgminer-ttyUSB0.conf

and here's the config file:

Code:

{
"pools" : [
        {
                "url" : "stratum+tcp://r6284.g21.rigs.eu.betarigs.com:9116",
                "user" : "chrison999-6284",
                "pass" : "x"
        },
        {
                "url" : "stratum+tcp://pool.ipominer.com:3333",
                "user" : "corion49.USB0",
                "pass" : "x"
        }
]
,
"failover-only" : true,
"failover-switch-delay" : "240",
"api-listen" : true,
"api-mcast-port" : "4035",
"api-port" : "4035",
"expiry" : "120",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "30",
"scrypt" : true,
"shares" : "0",
"kernel-path" : "/usr/local/bin",
"api-allow" : "W:127.0.0.1",
"usb" : ":1",
"request-diff" : "512",
"cmd-sick" : "pkill -9 bfgminer0",
"cmd-dead" : "pkill -9 bfgminer0",
"gridseed-options" : "baud=115200,freq=838,chips=40,modules=1,usefifo=0"
}

Can anyone see any errors in this or offer any suggestions on how to fix this problem?

Thanks!

Regards,

Chris

I'm actually having the exact same issue and trying to figure out what the problem is...

[1713560356]

1713560356

[1713560356]

1713560356

[1713560356]

1713560356

[rrob]

BUMP!

Just noticed I wasn't hashing for a couple hours because the failover wont go back to pool 0 and hash correctly. PLEASE FIX ASAP

Hey folks!

I'm bumping this because it's still a problem.  Can someone please give me a hand in fixing this?  Thanks!

I'm having a problem with bfgminer (both the new 4.2.0 version and the 4.1.99 jstefanop fork) with failover for both gridseed and zeus (GAWMiner fury) rigs.  Because it's happening with both versions I'm sure it's something dumb. so I thought I'd seek help here.

What's happening is that failover works going from pool 1 to pool 0 when pool 0 becomes active, but it doesn't work when pool 0 goes dead.  Bfgminer reports that it has switched back to pool 1 but the pool doesn't show any hashrate.  As well, my external monitor (CgminerMonitor version 0.7.0) shows the rig as still connected to pool 0.  Finally, I'm getting the following messages displayed in bfgminer:

Code:

[2014-06-16 19:26:49] Pool 0 slow/down or URL or credentials invalid
[2014-06-16 19:27:02] Network difficulty changed to 792 ( 5.68G)

When it's doing this, it sometimes changes the network difficulty several times, then give the "pool 0 slow/down" message again, but it's not accepting shares.

Here's how I'm running bfgminer for the furys:

/root/bfgminer/bfgminer --scrypt -S zeus:/dev/ttyUSB0 --nocheck-golden --chips-count 6 --ltc-clk 328 --config=/opt/cgminer/cgminer_conf/cgminer-ttyUSB0.conf

and here's the config file:

Code:

{
"pools" : [
        {
                "url" : "stratum+tcp://r6284.g21.rigs.eu.betarigs.com:9116",
                "user" : "chrison999-6284",
                "pass" : "x"
        },
        {
                "url" : "stratum+tcp://pool.ipominer.com:3333",
                "user" : "corion49.USB0",
                "pass" : "x"
        }
]
,
"failover-only" : true,
"failover-switch-delay" : "240",
"api-listen" : true,
"api-mcast-port" : "4035",
"api-port" : "4035",
"expiry" : "120",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "30",
"scrypt" : true,
"shares" : "0",
"kernel-path" : "/usr/local/bin",
"api-allow" : "W:127.0.0.1",
"usb" : ":1",
"request-diff" : "512",
"cmd-sick" : "pkill -9 bfgminer0",
"cmd-dead" : "pkill -9 bfgminer0",
"gridseed-options" : "baud=115200,freq=838,chips=40,modules=1,usefifo=0"
}

Can anyone see any errors in this or offer any suggestions on how to fix this problem?

Thanks!

Regards,

Chris

I'm actually having the exact same issue and trying to figure out what the problem is...

[Riley600]

I'm still having issues with BFGminer and my Scrypt ASICs (GAWminer Fury and Gridseed Orbs).  BFGminer will accept shares from my pool for about 5 minutes and then it hangs and does not receive any further shares.  The hashrate will decline until I restart it.  I've tried playing with my config file, changing FIFO buffers, different versions of BFGminer but the result is still the same.  It runs and then proceeds to stop receiving shares shortly after it starts.  CPUminer and CGminer both work without any issues, so I'm having trouble rooting out the issue with BFGminer.  Does anyone have any ideas?  Thanks!

[Riley600]

The Si Labs drivers sometimes don't like to install on Win64. The Si Labs Cp210x FREE Tool includes the driver package and if you download and install the free tool, then the drivers will usually work.

I wonder if I'm having a driver problem because of this.  I'm not sure what the "free tool" is, could you please provide a link?  Thanks!

[Buchi-88]

Use this to find the correct package:

sudo aptitude search uthash

A list of programs will come up.  Just pick the -dev version that's at least 1.9.2.  Then run apt-get update and apt-get upgrade to make sure you're up to snuff...

The search will only have 1 hit so use this:

sudo apt-get install uthash-dev

The other thing I did when I first started mining was to go to google and type in Linux BTCGuild and found the steps necessary to install a miner.  Just get all the required programs first, then try installing BFGMiner

Thanks for your hint, but it's always the same:

checking whether HASH_ITER is declared... no
configure: error: Could not find HASH_ITER - please install uthash-dev 1.9.4+
root@sunwatch:/usr/src/bfgminer# sudo aptitude search uthash
i   uthash-dev                                   - A hash table and linked list for C structures
root@sunwatch:/usr/src/bfgminer# sudo apt-get install uthash-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
uthash-dev is already the newest version.
The following packages were automatically installed and are no longer required:
  libssh2-1-dev libssl-dev
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@sunwatch:/usr/src/bfgminer#

regards

[hurricandave]

The Si Labs drivers sometimes don't like to install on Win64. The Si Labs Cp210x FREE Tool includes the driver package and if you download and install the free tool, then the drivers will usually work.

I wonder if I'm having a driver problem because of this.  I'm not sure what the "free tool" is, could you please provide a link?  Thanks!

Its USBXpress Development Kit now. You want the latest version.
http://www.silabs.com/products/mcu/Pages/USBXpress.aspx

This is for people having issues installing the USB to UART VCP 210x drivers, I have used this to install to Silabs 210x driver packed on 5 different computers that would not install the driver package on Windows 64 bit OS's. Bitmain Antminer U1 & U2 were the first that I personally needed these drivers but since then I believe a few other brands use these with BFGMiner.

 It is a complete development tool so if you want to dig in and learn more its in there.

[Luke-Jr]

Anyone running git should note that when updating, they will need to re-run autogen.sh to pull in the latest ccan from upstream.

[ShadowHawk]

I tried using git to get the latest version of BFGMiner, but when I compiled it, BFGMiner wouldn't recognize my Rockminer? I'm not sure what I did wrong.

https://i.imgur.com/pP4v04H.jpg

[movellan]

Noticed when moving from 3.10 to 4.20 Block Erupter BES units are now recognized as BEE's when using -S erupter:all. Doesn't seem to be much difference in hash rate over time. Anything to be concerned about? TIA.

[nwoolls]

Noticed when moving from 3.10 to 4.20 Block Erupter BES units are now recognized as BEE's when using -S erupter:all. Doesn't seem to be much difference in hash rate over time. Anything to be concerned about? TIA.

Just a visual change (bugfix).

[movellan]

Noticed when moving from 3.10 to 4.20 Block Erupter BES units are now recognized as BEE's when using -S erupter:all. Doesn't seem to be much difference in hash rate over time. Anything to be concerned about? TIA.

Just a visual change (bugfix).

Thanks for replying. Also receiving this message on most startups and at random times therafter.

[2014-06-28 20:01:37] Failed to open Device Parameters registry key in lowl-vcom.c _vcom_devinfo_scan_windows__hubport():440: The system cannot find the file specified

[g4lt]

Is there ever going to be a method for hotswapping kernels between SHA and Scrypt?  Kinda want to get a dualminer, but don't want to completely shut off the more-lucrative SHA mining completely to mine Doge

[nwoolls]

Is there ever going to be a method for hotswapping kernels between SHA and Scrypt?  Kinda want to get a dualminer, but don't want to completely shut off the more-lucrative SHA mining completely to mine Doge

I'm not sure what you mean by "hotswapping kernels". Kernels are for GPU mining, not ASIC mining.

BFGMiner already supports Dual Mode mining with DualMiner ASICs, just not with the 5-chip GridSeed Orbs. I doubt that will ever be supported, as there is very little demand. Most controller software has already disabled or deprecated mining SHA with the Scrypt ASICs and newer Scrypt ASICs don't support the feature at all.

[g4lt]

Is there ever going to be a method for hotswapping kernels between SHA and Scrypt?  Kinda want to get a dualminer, but don't want to completely shut off the more-lucrative SHA mining completely to mine Doge

I'm not sure what you mean by "hotswapping kernels". Kernels are for GPU mining, not ASIC mining.

BFGMiner already supports Dual Mode mining with DualMiner ASICs, just not with the 5-chip GridSeed Orbs. I doubt that will ever be supported, as there is very little demand. Most controller software has already disabled or deprecated mining SHA with the Scrypt ASICs and newer Scrypt ASICs don't support the feature at all.

Okay, let me get to the deep problem, then we can come back and correct my crappy translation to shallow problem  I have a Radeon 4350 (what can I say, AGP board and not a lot of round tuit to gut it), and mined scrypt coins and bleeding-edge alts with it fine until Ubuntu trusty changed things so badly that the fglrx-legacy blew up and I couldn't mine anymore (they SAY that the rv710 will eventually get opencl in the radeon drivers, but I ain't holding my breath). I found I liked mining, so grabbed a cheap antminer to tide me over, knowing that I'd have to go SHA. Of course, when I fired up bfgminer right afterward, I had to move the old config file that had the --scrypt option within (which I now know was only to get the radeon to work with scrypt, and became mostly irrelevant when trusty ruined my rig's drivers) and all my scrypt pools because I was (understandably) getting all hwerrors.  This is fun, but I wanna get a dualminer and back to scrypt asap, and rotate through pools (and altcoins) like I used to, except use the antminer when I'm on a SHA pool and not have to do extra stuff when I rotate through a scrypt pool (ultimately, I'd like the radeon to follow the bouncy pools, but that can wait until the radeon actually plays opencl in the open-source driver).  TBH, I had thought that the dualminer wasn't even an option until I looked at the changelog the other day and realized that dualminers work natively under bfgminer (dualminer itself says you need a specially patched cgminer, which they haven't gotten the round tuit to get working in linux).  So how can I get bfgminer to happily realize the proper hardware to use when I point it at a given pool, or am I just spinning my wheels because of a mistaken belief (see radeon mess) that bfgminer needs assistance in doing the right thing?  

[nwoolls]

I'm excited to say that version 4.3 (and the current source in Git) now supports mining Scrypt using ASICs on Big Endian hardware, such as the 703n router running OpenWrt:

Code:

GSD0       | 20s:360.1 avg:361.6 u:171.3 kh/s | A:2 R:0+0(none) HW:0/none
ZUS0       | 20s: 1.45 avg: 1.42 u: 1.26 Mh/s | A:14 R:0+0(none) HW:1/6.3%
 [2014-06-29 23:35:34] Accepted 00ab553a ZUS 0  Diff 5m/3m
ALL 20s: 3.43 avg: 3.14 u: 2.94 Mh/s | A:35 R:0+0(none) HW:3/7.9%
ZUS1       | 20s: 1.40 avg: 1.43 u: 1.50 Mh/s | A:18 R:0+0(none) HW:2/9.5%
 [2014-06-29 23:35:46] Accepted 00622f22 ZUS 1  Diff 10m/3m
GSD0       | 20s:361.0 avg:361.6 u:152.6 kh/s | A:2 R:0+0(none) HW:0/none
ALL 20s: 2.88 avg: 3.03 u: 2.74 Mh/s | A:36 R:0+0(none) HW:3/7.7%
 [2014-06-29 23:35:55] Accepted 00d3ca5f ZUS 1  Diff 4m/3m
ZUS0       | 20s: 1.46 avg: 1.42 u: 1.22 Mh/s | A:15 R:0+0(none) HW:1/5.9%
 [2014-06-29 23:35:55] Accepted 00e8d459 ZUS 0  Diff 4m/3m
 [2014-06-29 23:35:59] Accepted 00d622b8 ZUS 0  Diff 4m/3m
 [2014-06-29 23:36:00] Accepted 0058b7d8 ZUS 0  Diff 11m/3m
 [2014-06-29 23:36:06] Accepted 00281489 ZUS 0  Diff 24m/3m
 [2014-06-29 23:36:10] Accepted 005315cc ZUS 1  Diff 12m/3m
ALL 20s: 3.02 avg: 3.05 u: 2.94 Mh/s | A:42 R:0+0(none) HW:3/6.7%
GSD0       | 20s:361.4 avg:361.6 u:137.5 kh/s | A:2 R:0+0(none) HW:0/none
ZUS0       | 20s: 1.46 avg: 1.43 u: 1.37 Mh/s | A:19 R:0+0(none) HW:1/4.8%
 [2014-06-29 23:36:19] Accepted 009af945 ZUS 0  Diff 6m/3m
 [2014-06-29 23:36:20] Accepted 000cfb89 ZUS 0  Diff 77m/3m
 [2014-06-29 23:36:22] Accepted 00228d7f GSD 0  Diff 28m/3m
 [2014-06-29 23:36:24] Accepted 00e108f1 ZUS 0  Diff 4m/3m
 [2014-06-29 23:36:25] Accepted 00ef9dea ZUS 0  Diff 4m/3m
 [2014-06-29 23:36:32] Accepted 00631445 ZUS 0  Diff 10m/3m
ALL 20s: 2.70 avg: 2.99 u: 3.10 Mh/s | A:48 R:0+0(none) HW:3/5.9%

Hardware:

http://wiki.openwrt.org/toh/tp-link/tl-wr703n

Bins:

https://www.dropbox.com/s/0ffntt6uto4n5fw/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
https://www.dropbox.com/s/f1a2ng2ox4800j1/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-sysupgrade.bin

Note: I give the FW bins nothing more than an "It Didn't Brick Mine" seal of approval.  

Edit: Here's an updated release, with notes and everything. This also includes the scripts I used to cross-compile BFGMiner and to create the OpenWrt image itself.

[nwoolls]

Some performance numbers running 10x ZeusMiner ASICs (6 chips) on a Raspberry Pi:

Code:

./bfgminer --scrypt -S noauto -S zus:all --set zus@/dev/ttyUSB6:ignore_golden_nonce=1 -o usa4.wemineltc.com:3333 -u x -p x
 
 [2014-06-30 02:41:37]
Summary of runtime statistics:
 
 [2014-06-30 02:41:37] Started at [2014-06-30 01:41:17]
 [2014-06-30 02:41:37] Pool: http://usa4.wemineltc.com:3333
 [2014-06-30 02:41:37] Runtime: 1 hrs : 0 mins : 20 secs
 [2014-06-30 02:41:37] Average hashrate: 13.6 Megahash/s
 [2014-06-30 02:41:37] Solved blocks: 0
 [2014-06-30 02:41:37] Best share difficulty: 15
 [2014-06-30 02:41:37] Share submissions: 498
 [2014-06-30 02:41:37] Accepted shares: 498
 [2014-06-30 02:41:37] Rejected shares: 0 + 0 stale (0.00%)
 [2014-06-30 02:41:37] Accepted difficulty shares: 10
 [2014-06-30 02:41:37] Rejected difficulty shares: 0
 [2014-06-30 02:41:37] Hardware errors: 45
 [2014-06-30 02:41:37] Network transfer:  77.8 /  64.1 kB  ( 21.5 /  17.7  B/s)
 [2014-06-30 02:41:37] Efficiency (accepted shares * difficulty / 2 KB): 0.15
 [2014-06-30 02:41:37] Utility (accepted shares / min): 8.26/min
 
 [2014-06-30 02:41:37] Unable to get work from server occasions: 0
 [2014-06-30 02:41:37] Work items generated locally: 2788
 [2014-06-30 02:41:37] Submitting work remotely delay occasions: 0
 [2014-06-30 02:41:37] New blocks detected on network: 16
 
 [2014-06-30 02:41:37] Summary of per device statistics:
 
 [2014-06-30 02:41:37] ZUS0       | 20s: 1.76 avg: 1.36 u: 1.11 Mh/s | A:46 R:0+0(none) HW:2/4.7%
 [2014-06-30 02:41:37] ZUS1       | 20s: 1.84 avg: 1.36 u: 0.91 Mh/s | A:35 R:0+0(none) HW:16/ 27%
 [2014-06-30 02:41:37] ZUS2       | 20s: 1.66 avg: 1.35 u: 1.13 Mh/s | A:44 R:0+0(none) HW:3/5.5%
 [2014-06-30 02:41:37] ZUS3       | 20s: 1.30 avg: 1.36 u: 1.39 Mh/s | A:56 R:0+0(none) HW:2/3.8%
 [2014-06-30 02:41:37] ZUS4       | 20s: 1.55 avg: 1.36 u: 0.95 Mh/s | A:38 R:0+0(none) HW:16/ 30%
 [2014-06-30 02:41:37] ZUS5       | 20s: 1.44 avg: 1.36 u: 1.74 Mh/s | A:72 R:0+0(none) HW:1/1.5%
 [2014-06-30 02:41:38] ZUS6       | 20s: 2.20 avg: 1.35 u: 1.07 Mh/s | A:47 R:0+0(none) HW:1/2.5%
 [2014-06-30 02:41:38] ZUS7       | 20s: 1.85 avg: 1.35 u: 1.13 Mh/s | A:44 R:0+0(none) HW:4/7.6%
 [2014-06-30 02:41:38] ZUS8       | 20s: 1.79 avg: 1.34 u: 1.36 Mh/s | A:54 R:0+0(none) HW:0/none
 [2014-06-30 02:41:38] ZUS9       | 20s: 1.76 avg: 1.36 u: 1.60 Mh/s | A:62 R:0+0(none) HW:0/none
 [2014-06-30 02:41:38]
Shutdown signal received.

[BRADLEYPLOOF]

I've got 3 Gridseed 5 chips.  I've got each of them running separate instances of BFGMiner so I can monitor them easily.  2 of them seem to run fine but one of them hashes for a while, then the speed starts to drop, then it goes to nothing.  I'm using windows XP Pro.  They all ran fine on Linux together on this current computer which I reformatted back to windows.  Don't ask me why, I just did.  I'm not sure if there are driver issues, or what the deal is.  On that machine on linux using CGminer 3.7.2, no problems.  Using an RPi and CGMiner I get lib_usb_error after 1/2 an hour and BFGMiner seems to only run 2 of them.  I may have had an incorrect line in the command (I was using --set-device \\.\=COMX:freq=xxx instead of --set-device gridseed@\\.\comx:freq=xxx) so it seemed like everything was running much slower.  I'll give that a whirl when I get home.  Any suggestions though to help the Windows version?  I've tried powered USB hubs, switching to different USB ports, rebooting, power cycling the gridseeds...nothing helps.

Thanks!

[Luke-Jr]

NEW VERSION 4.3.0, JUNE 30 2014

I plan to move 3.10.x to stable soon, so if you're still using 3.5.x, please upgrade and report any regressions (note them as such).

Human readable changelog:

• URI parameter #getcbaddr to request coinbase address from bitcoind or compatible servers for solo mining.
• When running on systems with a configured Bitcoin Core server, it is automatically configured as a final failover and used for local block submission (GBT pools only) to reduce the risk of a stale block.
• bitforce: Implement some last-minute Monarch interface changes.
• zeusminer: New driver for these scrypt ASIC devices.

Full changelog:

• Bugfix: zeusminer: Include config.h
• openwrt: Disable libusb via --without-libusb
• Avoid waiting for local bitcoind test if we have other pools defined already
• lowl-pci: Silence warning on big endian
• bitfury: Portability fixes, including big endian compatibility
• Bugfix: bifury: strtoll already implies native endian, no need to flip it again
• bitforce: Additional sanity checks, including ensuring our final queued count matches that seen by the device
• bitforce: Go back to ignoring race-triggered sanity check warnings for ZqX
• bitforce: Refactor FLB and queue flush sanity checks
• bitforce: Use binary FLB protocol for Monarch
• bitforce: Add bitforce_read function to deal with binary responses
• bitforce: Support for queue id based jobs
• Make work->device_id unsigned
• bitforce: Support device explicit "Scan Interval" to override hardcoded sleep times
• bitforce: Allow queued_max to exceed BITFORCE_MAX_QUEUED_MAX iff the firmware provides an explicit Queue Depth
• bitforce: Fix bitforce_chips_to_plan_for to work beyond 32 chips
• configure: Clean up zeusminer logic
• icarus: Use estimated hashes for hw errors (more accurate hashrate for devices where hw error values vary significantly from hashes performed)
• zeusminer: Bugfix: calculate work_division based on chips and cores
• Replace swabn with bswap_32mult (matching swap32yes parameters and performance)
• Bugfix: zeusminer: Correctly encode job header regardless of native endian
• zeusminer: support added for ZeusMiner scrypt ASICs
• icarus: refactoring: commenting ICARUS_INFO members
• icarus: Accept any power of two as a valid work_division
• icarus: option added for Icarus-based drivers to ignore the golden nonce during probe
• util: is_power_of_two function
• Bugfix: Display proper statline R and HW error percents for values < 1
• openwrt: Provide scrypt option
• Benchmark: Debuglog headers generated
• Bugfix: cpu: Fix scrypt CPU miner
• Bugfix: scrypt: Fix scrypt hash postprocessing for big endian
• Bugfix: scrypt: Correct endian handling in PBKDF2_SHA256_80_128
• scrypt: Add unit test for scrypt_1024_1_1_256_sp
• scrypt: Add unit tests for PBKDF2_SHA256_80_128 and salsa20_8
• Bugfix: Copy ALL the data with swap32to<native>
• Automatically add pool configured from bitcoin.conf for failover only
• Add failover_only pool flag, to avoid using it regardless of strategy
• Accept --default-config option to search and load default configuration files, even if user is specifying their own
• Use appdata_file_call to find BFGMiner config file(s)
• util: appdata_file_call and appdata_file_find_first functions
• ccan: Update to latest version (which includes floatval option support)
• Bugfix: Adapt quit function to new logging design
• Workaround GCC 4.6 initialisation bugs with BYTES_INIT
• Bugfix: Use int rather than ssize_t to type-match %d expectation
• Minor refactor of text-only mode: avoid wasting bottom line of console, and save status lines as they are replaced by log items
• Bugfix: Wake up wait_lpcurrent if its conditions for returning may have changed
• Defer determining --quit-summary default until it is needed, so hotplugged devices affect it
• Bugfix: In benchmark mode, only remove the new pools after putting them in the array, since the removal will try to remove it from the array
• Bugfix: Initialise struct pool in add_pool rather than halfway through startup
• URI parameter #getcbaddr to request coinbase address from bitcoind or compatible servers
• pool_set_uri function
• util: bytes_eq and bytes_assimilate
• Replace struct _cbscript_t with bytes_t for simplicity
• Bugfix: Parse userpass option with strchr rather than strtok to avoid usernameless passwords getting into the username field and being displayed
• Bugfix: Free old coinbase script before setting a new one
• util: upper_power_of_two_u32 function
• Avoid unnecessarily finding drivers in a loop
• lowl-pci: Never probe via -S *:all
• configure: Succeed even if the libblkmaker submodule is missing (only --with-system-libblkmaker)
• rockminer: Reset task timeout when queuing work
• rockminer: When we detect a task failure, check if we ought to grab a new work rather than resend
• rockminer: Add a time limit before resending work even outside of midtask state
• Bugfix: rockminer: Keep count of requested jobs properly
• make-release: Include ccan LICENSE symlinks as symlinks even in ZIP
• make-release: Ensure ccan licenses get included in source
• Bugfix: make-release: Correctly avoid unused parts of ccan
• make-release: Do builds with the official source release, to test that it works
• Bugfix: DevAPI: Make for_each_logical_proc work correctly
• Avoid double hashing of shares
• Create work_hash function to abstractly produce work->hash from work->data regardless of algorithm used

[nwoolls]

For those interested, here are updated 703n FW bins for BFGMiner 4.3:

https://github.com/nwoolls/BFGMiner-OpenWrt-Tools/releases/tag/v4.3.0-pr3

Tested with DualMiner, ZeusMiner, GridSeed 5-chip, G-Blade, LittleFury, AntMiner USB, Bi*Fury and Hex*Fury.

[BRADLEYPLOOF]

4.3.0 Works wonders on windows xp!!!  Super stable, super lower HW (using CGminer with same settings had 10x as many HW).  Going to use the RPi and see if I get any lib_usb_errors on it.  If not, I can switch to that and monitor from anywhere...Is there some way to configure BFGMiner so that I can use the internet on my phone to make changes, restart the miners, that kind of thing, rather than using putty and a computer?  I do have LemonSSH for my android phone, but being able to go to my IP address and punch something in would be handy too...