What's your current blockmaxsize for Eligius? If the protocol limit were raised to 2,000,000 bytes, would you raise your blockmaxsize?
Eligius's blockmaxsize will likely always be the largest possible on the network (minus breathing room to avoid potential bugs). That's not to say the blocks will always get that big - that depends on priorities, transaction fees, spam filters, etc... |
|
|
|
|
Bitcoin transactions "go through" instantly, just like credit cards.
It's just confirmation that takes an hour or more (credit cards take 6+ months!).
|
|
|
|
Seems I'm getting a Nanofury to replace a dead Bluefury. Anything I need to be aware of as regards getting the Nanofury working on BFGMiner on Linux (or indeed OpenWRT)?
You'll have to build hidapi for OpenWrt and recompile BFGMiner to use it. Cheers Luke-Jr. I think I'll stick to the RPi then.  I hear there are significant problems with Nanofury on the RPi's buggy USB stack... I plan to be looking into this in the upcoming weeks, but it may be a hardware issue I can't workaround. Aw crap. What about the Beaglebone Black? I don't think the USB is borked on it, is it? I've not heard any reports of success or problems on BBB, nor do I have one to test with myself (KnCMiner's is missing USB ports...) |
|
|
|
Seems I'm getting a Nanofury to replace a dead Bluefury. Anything I need to be aware of as regards getting the Nanofury working on BFGMiner on Linux (or indeed OpenWRT)?
You'll have to build hidapi for OpenWrt and recompile BFGMiner to use it. Cheers Luke-Jr. I think I'll stick to the RPi then. I hear there are significant problems with Nanofury on the RPi's buggy USB stack... I plan to be looking into this in the upcoming weeks, but it may be a hardware issue I can't workaround. |
|
|
|
Seems I'm getting a Nanofury to replace a dead Bluefury. Anything I need to be aware of as regards getting the Nanofury working on BFGMiner on Linux (or indeed OpenWRT)?
You'll have to build hidapi for OpenWrt and recompile BFGMiner to use it. |
|
|
|
I think in sense of acceptance the CoinControl stuff should get into the 'official' release ASAP. It is already merged into what will become 0.9. One question is still open for me, however: the CC stuff uses the 100 addesses generated when the wallet was created, right? Will it - when the 100 addresses for change are used - generate 100 new ones or one-by-one with any transaction? So, I unsure about the backup strategy for the wallet... Bitcoin-Qt will create a new address every transaction, to ensure you always have 100 unused. So I recommend backing up every 90 transactions. Note this is entirely unrelated to coincontrol... |
|
|
|
need help
When i suppose to send few of (not working bitburner fury boards)? FOR REPAIR
ANY contact will be great
thanks
This is the HashBuster thread, not BitBurner... |
|
|
|
Hi Luke, I am having real problems with libhidapi and I was wondering if you could lend a hand. I have compiled and build the libraryies and ldconfig see's them;- ldconfig -vvv | grep libhidapi libhidapi-libusb.so.0 -> libhidapi-libusb.so.0.0.0 libhidapi-hidraw.so.0 -> libhidapi-hidraw.so.0.0.0 But after I git clone ./autogen.sh and ./configure I get;- ...
checking for LIBUSB... yes
checking for hidapi... no
checking for hidapi... no
checking for hidapi... no
checking whether libusb_error_name is declared... yes
...
Disabled.Drivers.....: cpu hashbuster knc metabank nanofury opencl
To enable nanofury, install hidapi
To enable hashbuster, install hidapi Any clues? What do you get when you ldconfig -vvv | grep libhidapi? Perhaps I have done something wrong in the compile? hidapi is loaded dynamically at runtime. Building just requires the header. Hopefully this will help you identify what's wrong with your install. Maybe check config.log to see exactly what's going on.. |
|
|
|
So I went to order something from the store on Eligius. I added it to the cart. Then I go to where? I don't see anywhere to do payments etc? Am I blind?
The message "HashBuster Micro added to your cart." has a link for "your cart". http://eligius.st/~gateway/cartI'll note the lack of another way to get there to Gateway69.. |
|
|
|
Also, how hard would it be to add share log file rotation? Mine grows out of control.
Already supported. |
|
|
|
I just had an idea I want to throw here, and you'll do whatever you want with it:
It would be great you could run a similar pool for Litecoin! It's one of the few trustable altcoin, and it's pretty much the last place we can spend CPU and GPU hashing power and not spend more in electricity.
Eloipool and wizstats are really well done software, and you guys seem really honest and devoted to your pool, so I believe it would be as awesome with Litecoin. It's because we're honest that we won't get involved with scams like Litecoin. |
|
|
|
NEW VERSION 3.8.0, DECEMBER 2 2013Human readable changelog:- New driver for HashBuster Micro boards.
- klondike: Add support for boards built with 55nm Avalon2 chips.
Full changelog:- Bugfix: lowl-usb.h: Add missing includes for stdbool/stdint
- hashbuster2: Retry writing request if no response received in 100ms
- lowl-usb: usb_ep_set_timeouts_ms function that behaves similar to termios VTIME (timeout before begin of read/write)
- hashbuster2: Use new lowl_usb_endpoint for i/o
- lowl-usb: Add tools for more reliable read/write using bulk transfers
- Add bytes_extend_buf, bytes_preappend, bytes_postappend for reading direct to a bytes_t
- New / updated instructions for building bfgminer on Windows
- configure: Adjust header-path discovery to work sanely with spaces and backslashes in paths
- Bugfix: configure: More fixing BSD sed syntax for curses header search
- bitfury: Reinitialise chips if their frequency drops over 50%
- bfg_strerror: Trim C whitespace off the right of FormatMessage output, since Windows can add \r\n
- Demote commonish errors to debug loglevel
- klondike: Add support for Avalon2-based designs
- klondike: Remove unnecessary limit of 999 on clock speed displayed in Manage Device
- Bugfix: hashbuster2: Claim USB device internally
- Bugfix: hashbuster2: Do not try to use lowl-hid.h
- Bugfix: hashbuster2: Close device and free memory allocated, when no chips are found
- Bugfix: hashbuster2: Remove libusb init and debug level setting
- Bugfix: hashbuster2: Avoid add_cgpu when no chips found
- Bugfix: klondike: Claim USB device internally
- Bugfix: devpath_to_devid: Check stat for error before allocating memory
- Bugfix: lowlevel: Free hash table data when done with it
- Bugfix: bifury: Free memory used by version reply
- bfgtls: Implement destructor to free memory when threads exit
- hashbuster2: Remove unnecessary libusb_detach_kernel_driver
- hashbuster2: Read unique serial number from device
- hashbuster2: Use hashbuster2_io for probe
- hashbuster2: Clean up warnings about unused variables
- README: Document --enable-opencl configure option
- README: Update for HashBuster Micro
- hashbuster2: Integrate into BFGMiner as a separate driver
- hashbuster2: Import driver for new protocol
- Bugfix: nanofury: Check if mcp2210_device exists before trying to power it off
- Bugfix: lowl-vcom: Check for error getting root hub path
- openwrt: Update package description
- configure: Add --without-libusb option to explicitly disable using it
- Bugfix: Pass newlines as ASCII (fixes lack of them in non-unicode builds)
|
|
|
|
Hey wizkid057,
Would it be possible to have the stats display per-worker revenue (in BTC, cumulatively)? I would like to be able to use one payment address, but still see at a glance which miners have paid for themselves and which ones have not. I recognize you're too busy to implement it now with the recent chaos. Would it be possible to make this work retroactively so that in a few weeks (when you have time) we can see the earnings that are being made now?
If you do this, I'll dump 50 mBTC into the 1Stats address.
Alternately, if you point me to the relevant section of code, I can try to construct a patch myself.
Pretty sure what you're asking here is a major overhaul, and balances are not tracker per-worker. |
|
|
|
[2013-11-30 14:30:59] hashbuster_lowl_probe: Identify sequence didn't match on \\?\hid#vid_fa04&pid_0011#6&11d06e40&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}This looks like a device-side issue, or something else interfering with BFGMiner talking to it. Got same error with clear WinXP on netbook, but all work fine with Linux Mint, and under VirtualBox on main machine, with custom cgminer. Mb my boards have some custom firmware? Confirmed this affects the Windows 7 laptop I test on, but also confirmed communication with the device seems to work. I don't know why the device fails when plugged into Windows  |
|
|
|
[2013-11-30 14:30:59] hashbuster_lowl_probe: Identify sequence didn't match on \\?\hid#vid_fa04&pid_0011#6&11d06e40&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}This looks like a device-side issue, or something else interfering with BFGMiner talking to it. Got same error with clear WinXP on netbook, but all work fine with Linux Mint, and under VirtualBox on main machine, with custom cgminer. Mb my boards have some custom firmware? Ah, interesting. I'll go test on Windows then...  |
|
|
|
[2013-11-30 14:30:59] hashbuster_lowl_probe: Identify sequence didn't match on \\?\hid#vid_fa04&pid_0011#6&11d06e40&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
This looks like a device-side issue, or something else interfering with BFGMiner talking to it. |
|
|
|
I get this output when running the git you linked to with my optimal scrypt settings that worked with 3.2.1, then it immediately crashes: C:\Users\BigMiner\Desktop\New folder>bfgminer.exe --scrypt -I 13,19,19,19 --thr
ead-concurrency 16384,22400,22400,22400 --gpu-engine 1045,1150,1050,1050 --gpu-m
emclock 1450,1420,1425,1425 -w 256,256,256,256 --auto-fan --failover-only --gpu-
powertune 0,20,20,20 --scan-serial all --scan-serial opencl:auto -o pool1.us.mul
tipool.us:3345 -u user -p "" -d 0 -d 1 -d 2 -d 3 -T
[2013-11-29 19:30:51] Started bfgminer 3.7.0
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] Failed to get PortName registry key value in lowl-vcom.c
_vcom_devinfo_scan_windows__hubport():443: The system cannot find the file speci
fied.
[2013-11-29 19:30:51] Failed to ioctl (1) in lowl-vcom.c windows_usb_get_root_h
ub_path():497: The operation completed successfully.
[2013-11-29 19:30:53] Twinfury: Not a valid response from device (-1)
[2013-11-29 19:30:54] klondike_lowl_probe: Matched "(null)" serial "(null)", bu
t lowlevel driver is not usb!
[2013-11-29 19:30:56] x6500_lowl_probe: Matched "(null)" serial "(null)", but l
owlevel driver is not ft232r!
[2013-11-29 19:30:56] ztex_lowl_probe: Matched "(null)" serial "(null)", but lo
wlevel driver is not usb!
[2013-11-29 19:31:00] Read of fd 3 returned 0
[2013-11-29 19:31:00] nanofury_lowl_probe: Matched "(null)" serial "(null)", bu
t lowlevel driver is not mcp2210!
[2013-11-29 19:31:00] hashbuster_lowl_probe: Matched "(null)" serial "(null)",
but lowlevel driver is not hid!
[2013-11-29 19:31:00] hashbuster2_lowl_probe: Matched "(null)" serial "(null)",
but lowlevel driver is not usb_generic!
[2013-11-29 19:31:02] Probing for an alive pool
[2013-11-29 19:31:03] Pool 0 http://pool1.us.multipool.us:3345 alive
[2013-11-29 19:31:03] Network difficulty changed to 1 (13.44Mh/s)
[2013-11-29 19:31:03] Stratum from pool 0 detected new block
[2013-11-29 19:31:03] Pool 0 is hiding block contents from us
Please add --debuglog --log-file 20131130-purelithium-debug.log and send me the file. Done, you should have it now. Looked at the log and I think it's crashing when compiling the scrypt bitstreams... If it just ends abruptly like that on Windows, then it didn't crash... My only guess is your OpenCL drivers called exit() for some reason. If older versions work, we will need to bisect this issue while also ignoring the (different) bug you bisected earlier. Unfortunately, automating this process is difficult... can you meet me on IRC? |
|
|
|
I get this output when running the git you linked to with my optimal scrypt settings that worked with 3.2.1, then it immediately crashes: C:\Users\BigMiner\Desktop\New folder>bfgminer.exe --scrypt -I 13,19,19,19 --thr
ead-concurrency 16384,22400,22400,22400 --gpu-engine 1045,1150,1050,1050 --gpu-m
emclock 1450,1420,1425,1425 -w 256,256,256,256 --auto-fan --failover-only --gpu-
powertune 0,20,20,20 --scan-serial all --scan-serial opencl:auto -o pool1.us.mul
tipool.us:3345 -u user -p "" -d 0 -d 1 -d 2 -d 3 -T
[2013-11-29 19:30:51] Started bfgminer 3.7.0
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-29 19:30:51] Failed to get PortName registry key value in lowl-vcom.c
_vcom_devinfo_scan_windows__hubport():443: The system cannot find the file speci
fied.
[2013-11-29 19:30:51] Failed to ioctl (1) in lowl-vcom.c windows_usb_get_root_h
ub_path():497: The operation completed successfully.
[2013-11-29 19:30:53] Twinfury: Not a valid response from device (-1)
[2013-11-29 19:30:54] klondike_lowl_probe: Matched "(null)" serial "(null)", bu
t lowlevel driver is not usb!
[2013-11-29 19:30:56] x6500_lowl_probe: Matched "(null)" serial "(null)", but l
owlevel driver is not ft232r!
[2013-11-29 19:30:56] ztex_lowl_probe: Matched "(null)" serial "(null)", but lo
wlevel driver is not usb!
[2013-11-29 19:31:00] Read of fd 3 returned 0
[2013-11-29 19:31:00] nanofury_lowl_probe: Matched "(null)" serial "(null)", bu
t lowlevel driver is not mcp2210!
[2013-11-29 19:31:00] hashbuster_lowl_probe: Matched "(null)" serial "(null)",
but lowlevel driver is not hid!
[2013-11-29 19:31:00] hashbuster2_lowl_probe: Matched "(null)" serial "(null)",
but lowlevel driver is not usb_generic!
[2013-11-29 19:31:02] Probing for an alive pool
[2013-11-29 19:31:03] Pool 0 http://pool1.us.multipool.us:3345 alive
[2013-11-29 19:31:03] Network difficulty changed to 1 (13.44Mh/s)
[2013-11-29 19:31:03] Stratum from pool 0 detected new block
[2013-11-29 19:31:03] Pool 0 is hiding block contents from us
Please add --debuglog --log-file 20131130-purelithium-debug.log and send me the file. |
|
|
|
Same here. Windows 7 x64.
bfgminer -D -d? finds this:
[2013-11-30 00:47:06] lowlevel_scan: Found hid device at hid:\\?\hid#vid_fa04&p
id_0011#6&11d06e40&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} (path=\\?\hid#v
id_fa04&pid_0011#6&11d06e40&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}, vid=f
a04, pid=0011, manuf=StarFury Laboratories, prod=HashBuster.nano Project, serial
= )
But i only get "waiting for devices: press m+ to add, or q to quit."
Can anyone help? I need the whole output from -D -d?I'm baffled as to why bfgminer keeps crashing on this system. Why is it looking for USB devices when I'm trying to mine scrypt?
C:\Mining\bfgminer-3.7.0-win64>bfgminer.exe --scrypt -T
[2013-11-27 20:36:26] Started bfgminer 3.7.0
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_
SUPPORTED
[2013-11-27 20:36:26] Failed to get PortName registry key value in lowl-vcom.c
_vcom_devinfo_scan_windows__hubport():443: The system cannot find the file speci
fied.
[2013-11-27 20:36:26] Failed to ioctl (1) in lowl-vcom.c windows_usb_get_root_h
ub_path():497: The operation completed successfully.
C:\Mining\bfgminer-3.7.0-win64>
I used WeBisect session "purelithiumNov29" to try and bisect the problem. This is what it gave me once I bisected all I could: There are only 'skip'ped commits left to test.
The first bad commit could be any of:
e61f3a480388cfabe4dd7ddcbd643c6d7390c751
745bd11dc27a745f42fdb2361da60e0ca5bc5fa6
dd43825dbb5300d8509e7da8bba4d4599a98f719
ebf66582ace0fe5b7162f2d896a5b59043707a85
fd7d89dfef7398bedfd7d6f00ac6601a441a2d28
a651e94616c4c3c5eb9aefc7b2c350e8793e6628
ce4eba9042cdd3070a9770699987cd3d4005fc2f
f84c1a473f8618c46750701c249eddbf940d240f
We cannot bisect more! The build I got before that message didn't have the error I described in my quoted message, but It did have another issue of crashing almost immediately on connecting to a pool. Not sure how I could bisect that one... As of right now 3.2.1 is the only functional build for my machine. Please test the latest git: http://luke.dashjr.org/tmp/code/webisect/webisect.php?dobuild=bfgminer |
|
|
|
|
Show Posts
