I am searching for BFGMiner love. I have the newest version 3.5 running but it doesn't identify my miners. Is WinUSB the correct USB driver to use?
No, WinUSB is always the wrong driver for ASICs. Chilis are FTDI: http://ftdichip.com/Drivers/VCP.htmInteresting. I am using WinUSB CGMINER. That would explain why BFG miner isn't working though. Yes, cgminer requires the wrong driver. But we were talking about BFGMiner... |
|
|
|
Also, Is the current version of bfgminer good for mining litecoins? Because in the litecoin Mining hardware comparison I see a lot of references to older versions. I'm assuming the document is out of date. I don't see a lot of info for setting up bfgminer to mine litecoins. I don't support scams like Litecoin, but I'm not aware of any reason it wouldn't work. Maybe someone else who knows or cares about it can provide more helpful advice (and maybe even take over maintaining scrypt in BFGMiner?). Luke: The README.txt refers to a README.GPU, but there is not such document in the 3.5.0 release. Thank you for reporting this bug, I will make sure I get it fixed in 3.5.1.  |
|
|
|
Luke the latest works with that command. Thank you Thank you.
Can I run that in conjunction with my ASIC Miner usbs? Or do I have to call out all of them separately?
As long as you don't use -S all (or any variant of all) |
|
|
|
I'm having absolutely no luck at all with the Blue Fury and BFGMiner
Details? OS? Did you install the driver (if Windows)? Windows 7 64 bit, Yes I installed the driver. I can get it to work with the BFGMiner they included in the driver package but thats it. Tried your latest version and version 3.2 which worked pretty well for me. I have your latest (i call it 3.5.1) running AM eruptors in the next room. But this thing doesnt like the new versions. Let me know what I can do to help! BTW windows sees my Blue Fury Can you try with -S bigpic:\\.\COMn where n is the number of the COM port it uses? Be sure you don't do anything between plugging it in fresh, and trying it this way... Edit: Only slightly more importantly, if you download latest git again (it's changed more), does it work? |
|
|
|
Downloaded the latest version, bfgminer detects my gpus but not my hashbusters. Something about libusb not supported error comes up quickly when I scan for devices. Would I need to start the miner with special commands?
Shouldn't... Can you paste the output of: Only one hashbuster connected to this rig atm. Does Windows see it? I'm using a virtualbox to mine with it just fine. The device gets detected as some usb device, then a virtualbox usb driver is installed by windows. I'm using windows 7 64 bit by the way. It works fine in the virtual box, but I get an error whenever I want to use more than one device in the virtualbox. Probably some driver issue. That's why I was hoping for an out of the box solution that would support multiple miners on one computer. (Yes, my current "solution" to the problem is to have as many computers as I have hashbuster nanos. Lol) I wonder if the VirtualBox driver messes up the normal one... |
|
|
|
These is new firmware?
How I install it?
No, it's the same firmware that shipped on the second half of the first batch. Open ChiliFlash, and select the Chili that needs to be flashed from the drop down menu. Browse the the ChiliFW14c.hex hex file, and then hit program. The LEDs on the board should binary count quickly, and when it's done it will prompt to power cycle the unit and the LEDs should flash outer 4 then inner 4 until you do. Is there a way to determine a board's current firmware version with a serial console? I don't know if I already have 14c, and they're connected to a linux pc. I tried the ZCX command but the output doesn't appear to include the firmware version. No, not right now. Unfortunately cgminer uses the FW version to determine if it should be using per chip or per board work queuing, so we need to keep 1.0.0. I've edited my personal copy to report back 1.0.14c and it works although cgminer throws a warning. I haven't tested it on Bitminter or bfg though so I don't want to do it until I have a chance to test it in case that breaks compatibility. It's definitely on the to do list though. BFGMiner doesn't do anything based on the version (because that'd be stupid and cause problems like you've found..). |
|
|
|
I am searching for BFGMiner love. I have the newest version 3.5 running but it doesn't identify my miners. Is WinUSB the correct USB driver to use?
No, WinUSB is always the wrong driver for ASICs. Chilis are FTDI: http://ftdichip.com/Drivers/VCP.htm |
|
|
|
I'm having absolutely no luck at all with the Blue Fury and BFGMiner
Details? OS? Did you install the driver (if Windows)? |
|
|
|
Downloaded the latest version, bfgminer detects my gpus but not my hashbusters. Something about libusb not supported error comes up quickly when I scan for devices. Would I need to start the miner with special commands?
Shouldn't... Can you paste the output of: Only one hashbuster connected to this rig atm. Does Windows see it? |
|
|
|
Downloaded the latest version, bfgminer detects my gpus but not my hashbusters. Something about libusb not supported error comes up quickly when I scan for devices. Would I need to start the miner with special commands?
Shouldn't... Can you paste the output of: |
|
|
|
3.5.0 should work fine, no need for bleeding edge anymore bfgminer.exe -o stratum+tcp://mint.bitminter.com:3333 -u vs3_nanofury1 -p nanofury1 -G -S all --set-device NFY:osc6_bits=52 Can i write this part into the config file? what is the correct form for this? ... "set-device":["NFY:osc6_bits=52"], ... |
|
|
|
Love the no registration/no fee pool. Keep up the great work WK. I'll gladly take the student moniker in this incredible field of work. ----------------------------------------------------------------------------- My issue: CampBX has started killing addresses after a week, Guess they don't like miner outputs. As a new Eligius Miner, My first day was run using CampBx. I stopped, and redirected output to a static address. But now final payout (commencing after 7 days) will be to a "deleted" CampBx address. It's not much but still... It may be a dumb question but I must ask, is there a way to redirect these final payouts? Since the Miners are I.D.d, can we request old output from said miner, be sent to current output for said miner? I can't find anything poking around Eligius menus. ----------------------------------------------------------------------------- Willingly studying under experts as I pursue my Btc Phd. Then "change mining address". That won't work... |
|
|
|
BFGMiner 3.5.0 is released bfgminer version 3.5.0 - Started: [2013-11-06 00:08:13] - [ 0 days 01:38:39]
[M]anage devices [P]ool management [S]ettings [D]isplay options [H]elp [Q]uit
Connected to mining.eligius.st diff 2 with stratum as user 1DpdSGEv2S64E4q1q3YgQFKUfMPsBkAzwv
Block: ...cface391 #268197 Diff:511M ( 3.66Ph/s) Started: [01:47:14]
ST:2 F:0 NB:11 AS:0 BW:[133/ 38 B/s] E:7.78 I: 116uBTC/hr BS:2.49k
1 | 2.84/ 2.83/ 2.84Gh/s | A:1940 R:5+0(.26%) HW:4/.10%
--------------------------------------------------------------------------------
HBR 0: | 2.83/ 2.83/ 2.84Gh/s | A:1940 R:5+0(.26%) HW:4/.10%
--------------------------------------------------------------------------------
[2013-11-06 01:46:00] Accepted 311061ec HBR 0 Diff 5/2
[2013-11-06 01:46:02] Accepted 0e3f2150 HBR 0 Diff 17/2
[2013-11-06 01:46:03] Accepted 08f2b5c8 HBR 0 Diff 28/2
[2013-11-06 01:46:06] Accepted 722a295e HBR 0 Diff 2/2
[2013-11-06 01:46:07] Accepted 786f7d67 HBR 0 Diff 2/2
[2013-11-06 01:46:09] Accepted 2c6ae091 HBR 0 Diff 5/2
|
|
|
|
NEW VERSION 3.5.0, NOVEMBER 6 2013Not as big a release as originally planned - I still have a stack of devices waiting for me to write drivers... but they'll come soon. Notably, this release does not include the planned TechnoB⃦it driver due to technical complications with Linux. Human readable changelog:- hashbuster: New driver for HashBuster nano ASIC miners.
- littlefury: Updated driver to use latest bitfury code.
- Autodetection support for Windows extended to all VCOM-based devices (instead of just FTDI, libusb, and hidapi); this includes at least ModMiner, Big Picture Mining (BF1, RedFury, BlueFury), and USB Block Erupters.
- Reworked autodetection to scan system devices once and share results with all drivers.
Full changelog:- bigpic: Probe sooner than most drivers, but still after icarus/erupter
- cpu/opencl: Fix probe priorities to be last
- Bugfix: RPC: Correct per-device Work Utility to be per-minute instead of per-second
- Bugfix: Fix Windows VCOM enumeration to work with new lowlevel code
- Bugfix: nanofury: Use maybe_strdup in case strings may be missing
- Bugfix: bitfury: Fix processor disable/enable for all bitfury-based devices
- hashbuster: Get temperature when available
- Bugfix: hashbuster: Use maybe_strdup where there might not be a string
- hid: Treat null-length strings as missing entirely
- hashbuster: Enable dynamic osc6_bits
- hashbuster: New driver
- Split a hid lowlevel out of mcp2210
- ztex: Convert to use lowlevel usb enumerator
- A quick flag to allow drivers to convey the desire to rescan devices (from lowlevel up)
- Lowlevel USB enumerator for libusb
- dname for lowlevel drivers
- Bugfix: lowlevel: Avoid null pointer dereference on devices that are missing USB strings
- lowlevel: Add a userpointer to lowl_found_devinfo_func_t and use it for serial_autodetect
- Rework VCOM autodetection to go through lowlevel interface, avoiding repeat USB string fetching
- lowlevel: Keep track of the claimed devid and debuglog every found device
- ft232r: devinfo_scan: Don't skip claimed USB devices
- ft232r: Be more tolerant of USB open failure or missing strings
- RPC: Build most of CONFIG "Device Code" by iterating over registered driver list
- drv_detect_all: Use priority-sorted list of registered drivers
- Build hash tables to find drivers by dname or name
- Build a linked list of registered drivers
- BFG_REGISTER_DRIVER macro to commonly pre-define device_drv structures
- Move have_libusb checks out of drv_detect_all
- Replace opt_nogpu with simple function that adds opencl:noauto to scan-serial list
- opencl: Remove ancient gpu_threads variable, not really needed anymore
- Bugfix: Stop waiting for pool testing as soon as one is active
- bitfury: Clean up by making private functions static, and naming public ones with [lib]bitfury_ prefix
- bitfury: Remove old (unused) driver code
- bitfury_gpio: Convert to using current bitfury driver code
- Bugfix: littlefury: Upgrade to use current bitfury driver (old one didn't work with littlefury anymore anyway)
- Bugfix: test_work_current: Make hexstr buffer large enough for blkhashstr later on (issuing old work msg)
- README: Document --enable-knc configure option
- README: Document --disable-nanofury configure option
- Windows autodetect: clear detectone meta info
- Check for Windows DDK headers, and where they are (and build without them if unavailable)
- Windows SetupAPI-based detection for USB VCOM devices (tested with CP210x and CDC)
- ucs2tochar{,_dup} functions to convert USB string descriptors to char* format
- bfg_strerror: Support for Windows system errors
- Introduce applogfail* macros
- Bugfix: scrypt: Add missing include stdbool.h
- Bugfix: Explicitly cast uses of be32toh to uint32_t
- Bugfix: Add missing includes of config.h, stdbool.h, and stdint.h
- lowlevel: Convey device manufacturer up to nanofury cgpus
- nanofury: Store device HID path for RPC
- lowlevel: Promote path to a normal element for devices to simplify things a bit
- nanofury: Claim mcp2210/hid devices
- mcp2210: Implement claim on HID paths
- fpgautils: Use string identifiers for internal hardware claims
- ztex: Keep interface claimed as a lock
- Bugfix: mcp2210: Check for NULL hid device strings before trying to convert them to ASCII
- FTDI autodetect: Enable populating USB product and serial number
- Bugfix: FTDI autodetect: Add missing parameter values and remove unused buffer
- Bugfix: bigpic: Don't active poll event without a poll function
|
|
|
|
Unfortunately, it seems to get many facts wrong too... - The timestamp in the block header is entirely ignored, and the block-discovered-first isn't reported at all (nodes know which they saw first, and that's all they care about)
- No mention of the fact that there are many better sybil attacks should sybil-ing be possible.
- The proposed solution doesn't limit pools to 25% (this isn't even theoretically possible).
|
|
|
|
Given its ubiquity it controls the Bitcoin network. Why do you give it ubiquity? It is an attribute which emerges from widespread adoption. I think you underestimate adoption of MultiBit, Armory, and Electrum. On the full node front, there's a bit more of a ubiquity problem, but that's the fault of users, as I already hinted. Are you using any of them to help improve the situation? No? Then you're part of the problem. We have at least Picocoin and libbitcoin/SX now. Go switch to one. |
|
|
|
Given its ubiquity it controls the Bitcoin network. Why do you give it ubiquity? |
|
|
|
Would it be possible to reduce the centralised power from large pools through the following method?
- The pool simply provides the miner with the pool's payout address
- The miner can build whatever block they want, so long as it contains a coinbase output which pays the pool with amount (BLOCK_REWARD - MINER_BONUS).
- The miner bonus is a second output added to the coinbase transaction which the miner can pay to him/herself. It could be 1% of the block reward or something like that. This gives the miner a direct financial incentive to publish blocks they find immediately.
- The pool accepts the work from the miner so long as it contains the coinbase transaction that pays the pool.
* Possibly there could be some variation on this protocol so that the miner doesn't have to track transactions and build their own merkle tree. Eg. the pool operator could provide a suggested merkle tree to the miner, and the miner just has to communicate any desired changes back to the pool operator, which reduces the bandwidth required.
This is essentially what GBT aims to do. |
|
|
|
1. Semantics. There is a defacto official client. Which client is that? Why have you decided to make it a defacto official client? |
|
|
|
|
Show Posts
