5.1 update problem
HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl
easyminer running BFL machine.
This message is normal (libcurl does not support stratum, so BFG uses its own). Is there an actual problem? Will not connect after 5.1 update Will not connect to ghash pool Been running with no hitches on the same settings for over a year now Updated this morning and get this error code , wont connect. Can you upload a full debug log to Google Drive and send me a link? bfgminer --debuglog --log-file debug.log |
|
|
|
5.1 update problem
HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl
easyminer running BFL machine.
This message is normal (libcurl does not support stratum, so BFG uses its own). Is there an actual problem? |
|
|
|
Many thanks. May I ask what is the quick test to know that my system is practically useful? I mean how fast it should be as I read in the CPU README, you said it not worth it to try. As I am new to bitcoin miner, please advice what I would expect and should do/do not. Thanks, John. Bitcoin mining with a CPU, no matter what kind of CPU, will never be practically useful for more than testing. |
|
|
|
Have been using BFGMiner 5.0 with Bitcoin Core 9.3 to do some solo mining. Just switched to the new 10.0 Core and now BFG doesn't see any pool available. Using same "bitcoin-qt.exe -server" command to run Bitcoin. What am I missing? TIA. You mean 0.10, which had release notes explaining that it included BIP66, and also that this means you need to upgrade your miner... BFGMiner 5.1's release notes also mentioned the need to upgrade. |
|
|
|
Hi Luke,
I would like to use my multi-core/clusters and special coprocessors for mining. I would like to write my special drivers (CPU/cluster based). Where is in the source code I should make change or start from?
Thanks, John
If your system supports OpenCL already, you may be able to just replace CL_DEVICE_TYPE_GPU in ocl.c If it's similar enough to the existing CPU mining, driver-cpu.c may be the place to hook into the CPU mining stuff. If it needs an entirely new driver, the HACKING document is a good reference. Started using BFGMiner with my KNCMINER Jupiter
is there anyway to temporarily disable mining within the software?
Like Pause mining ?
See README. I read both the README and README.ASIC and there is nothing about pausing or stopping mining. --sched-start <arg> Set a time of day in HH:MM to start mining (a once off without a stop time) --sched-stop <arg> Set a time of day in HH:MM to stop mining (will quit without a start time) You can also manually either disable all devices (individually) or disable all pools. |
|
|
|
Hi Luke,
I would like to use my multi-core/clusters and special coprocessors for mining. I would like to write my special drivers (CPU/cluster based). Where is in the source code I should make change or start from?
Thanks, John
If your system supports OpenCL already, you may be able to just replace CL_DEVICE_TYPE_GPU in ocl.c If it's similar enough to the existing CPU mining, driver-cpu.c may be the place to hook into the CPU mining stuff. If it needs an entirely new driver, the HACKING document is a good reference. Started using BFGMiner with my KNCMINER Jupiter
is there anyway to temporarily disable mining within the software?
Like Pause mining ?
See README. |
|
|
|
Hi, I run bfgminer with -S \\.\COM9 \\.\COM10 \\.\COM11 but still my USB memory stick doesn't want to mount properly.
Whenever I plug something into a USB port I see bfgminer complaining about something (can't remember, remote location) so it's definetly not sticking to those COM ports...
How can I force bfgminer to not spam my whole USB circuit?
That's the default behaviour (not probing unrecognised devices) - maybe you have a config file somewhere overriding it? Well, I don't think it's probing that is the problem. It seems bfgminer is doing something (maybe just communicating with the miners) that disturbs win from finding the USB flash memory. It mounts, but it's empty; I thought the USB stick was fried but then at another location it works fine. Will try mounting it without the miners/bfgminer on next time maybe it's something else that's broken. Maybe try with --no-hotplug ? |
|
|
|
I am "solo" mining in ckpool because it keeps me from having to run a full node at work (which I can't do, but I do at home), and I like that this pool is lightweight and connected to high speed low latency bitcoin nodes for rapid block change notification and propagation. What I am hoping to achieve is to contribute, albeit negligibly, to the Bitcoin network while giving myself a lottery ticket that plays every 10 minutes. I suppose it makes sense if you're after the "thrill" of gambling, but do note this doesn't contribute to the network any more than using a pool sharing rewards between miners. The entire network benefit of solo mining, comes from the locally administrated full node. I don't seem to be finding any shares, however, which seems odd to me. Command line display shows it chugging along at ~2.1gh, but not finding shares. Not sure if that is a BFGminer issue or not. Been running 10 minutes now and no shares  . Could this be a difficulty setting issue? Note that real solo mining does not use shares. ckpool's server appears to use diff ~1k shares, which should take about 35 minutes on average per share with 2.1 Gh/s. I don't see that BFGminer supports --suggest-diff or anything of that sort. [edit, found option --request-diff, which I think is the same thing, tried using it with value 6 and it would not connect to pool, so maybe not what I was looking for]
ckpool does not support request-diff, and instead implemented (over a year later IIRC) an incompatible way to do the same thing in an apparent effort to push people away from BFGMiner. If you don't like their diff 1024 target, perhaps the best option is to run a private poolserver on your full node? Eloipool can help with that if it's a Linux system. |
|
|
|
Hi, I run bfgminer with -S \\.\COM9 \\.\COM10 \\.\COM11 but still my USB memory stick doesn't want to mount properly.
Whenever I plug something into a USB port I see bfgminer complaining about something (can't remember, remote location) so it's definetly not sticking to those COM ports...
How can I force bfgminer to not spam my whole USB circuit?
That's the default behaviour (not probing unrecognised devices) - maybe you have a config file somewhere overriding it? |
|
|
|
My guess would be that the bc address is invalid. I've confirmed that pool seems to work fine (with regard to login).
If you actually want to solo mine, though (which using any third-party operated server is not), just configure and run Bitcoin Core with the RPC server enabled, and skip the -o/-u/-p options.
Double checked the btc address, it is correct. Please pastebin (or share a Google Drive file with me) a debug log made by bfgminer -P --debuglog --log-file debug.log There are advantages to ckpool over pure solo mining that I wish to make use of; that pool is as close to solo mining as it comes without technically solo mining. So-called "solo pools" are frankly all the disadvantages of solo mining combined with all the disadvantages of pool mining, with none of the advantages of either. What exactly are you hoping to achieve? O.o I tried configuring BTC core with RPC server enabled, however, since I have moved my block chain data from the default location I have yet to have any luck getting that to work, either. As I said, new BTC user here.  You can use the -datadir=/path/to/.bitcoin/directory/ to override where Bitcoin Core looks for stuff. |
|
|
|
Hello, new user here trying to get my first of two pieces of mining gear going. I have a Cryptorig Hitchhiker usb stick (Bitfury ASIC, same chip used in red fury, blue fury). I downloaded the latest BFGminer, plugged in my usb stick, and then launched BFGminer using the following: bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333 -u myBTCaddress.HH -p x -S all --set-device NFY:osc6_bits=50
The light on the ubs stick comes on briefly, the screen displays:
"Started bfgminer 5.1.0"
Then the light goes out, nothing happens on the screen, then it quits with:
"No server could be used! Exiting."
Any idea what I'm doing wrong? My guess would be that the bc address is invalid. I've confirmed that pool seems to work fine (with regard to login). If you actually want to solo mine, though (which using any third-party operated server is not), just configure and run Bitcoin Core with the RPC server enabled, and skip the -o/-u/-p options. |
|
|
|
Announcing BFGMiner 5.1, the modular cryptocurrency miner written in C. BFGMiner features dynamic clocking, monitoring, and remote interface capabilities.
(snip) The repository for Ubuntu seems to be stuck at 3.10.x, and for Arch Arm at version 3.9.x. AP Hmm, distros may need new maintainers if the old ones are slacking Anyone want to take care of these? |
|
|
|
NEW VERSION 5.1.0, FEBRUARY 19 2015Miners must upgrade to 3.10.9, 4.10.2, or 5.1.0 to continue using GBT pools post-BIP66 or solo mining with Bitcoin Core 0.10 or newer. Human readable changelog:- Update libblkmaker for compatibility with BIP66 version 3 blocks.
- Merge Kano's web-based config file loader from cgminer.
Full changelog:- Fix broken driver options in configure script
- Bugfix: extract_domain: Correctly handle query/fragment in URI without path
- kncasic: Do flush!
- kncasic: avoid duplicate nonces to be reported
- kncasic: Fix logging levels
- kncasic: Neptune-compatible API interface for enabling/disabling dies
- kncasic: Use one bfgminer processor per die (not per core)
- Update libblkmaker to 0.5.1
- Titan: Lower log level when reconfiguring dies
- Titan: does not need SHA256d algo
- Titan: lower log level for flush messages
- Titan: adjust log levels in knc_titan_get_info
- get_master_rolling_hashrate -> get_proc_rolling_hashrate
- Update webconfig code to latest BFGMiner
- allow url based config files
- kncasic: Fix "double free" error
- kncasic: We need to free queued work to avoid memory leaks
- Bugfix: minion: Don't try to add 0-chip devices
- configure: Avoid BASHisms for better portability
|
|
|
|
Eligius was the first implementation of this, but (aside from it being disabled temporarily) it's for humans, and automated systems should just use the usual bitcoin protocol to relay transactions.
With CPFP, you can just use a normal spend to add a fee to some tx..
I am not sure did I discussed it with you or with wizkid but what about f2pool referral system if they do something bad on their ref their key gets revoked.Also I made 3 tx's https://blockchain.info/tx-index/77712737 This tx should confirm on it's own though it paid 0 fee but the coins are old enough. Confirmedhttps://blockchain.info/tx-index/77714274 This tx doesn't have any coins age and pays 0 fee so no miner really wants to include it in their block. Confirmedhttps://blockchain.info/tx-index/77712774 This tx pays 0.001 fee that is more than enough for this tx and the previous. Lets see if CPFP occurs on Eligius. ConfirmedWas it did automatically or you did it manually?Ok the second tx was not that low in priority it was less than 300 Bytes and it wasn't spam(almost 1BTC in single input/output).What if the second tx were 16-18 KB having 100 outputs and then I spend one of those outputs(3rd tx) and set that all input as a fee and have a 0BTC output or lets just say that I send 0.0001(not spam) and have 0.0099 as a fee.Would that have done the same effect?If Eligius doesn't hold any low priority tx's in their mempool than they won't hold the second tx in the mempool thus meaning 3rd tx is invalid?Is that so?How can I come around it? When I saw your post, I did manually check Eligius's GBT result (anyone can do this using the GBT port ont he site..) and saw they were in fact included in the first few transactions - so unless wizkid057 was really fast, it was automatic. Eligius won't mine spam no matter how much the fee, so CPFP won't help if it detects a parent is spam; there is no way to get around this. |
|
|
|
Eligius was the first implementation of this, but (aside from it being disabled temporarily) it's for humans, and automated systems should just use the usual bitcoin protocol to relay transactions. With CPFP, you can just use a normal spend to add a fee to some tx.. Also how should I know if there is a certain transaction in your mempool?
You can use getblocktemplate to see what is in the current block template, but this is never a guarantee it will remain there. I am running antminer s4's on eligius and its getting 1.02k as difficulty always, theres no way to set minimum difficulty there, and as we know s4 discards difficulty less than 2048  I sent mesgs in irc chat but its a dead chatroom. Any help on this? Ask Bitmain for BFGMiner support - then I can provide a fixed firmware. |
|
|
|
I've noticed something interesting with the stats today, and I'm not sure what to make of it.
I have two Antminer S5s, one running at 387.5MHz and one at 400MHz, each with their own worker. I unplugged one (the 400MHz) about 13 hours ago, and I wanted to see what the 12 hour stats looked like. When I first checked, both workers had the same 12hr average down to the hundredth of a GH/s. I though it was a little weird but just figured there was still some of the off time in there and it was a coincidence, so I waited for the next update. The 12 hr average diverged at the next update a little, but at this most recent update they are back to displaying not only the same hashrate, but exactly the same number of accepted shares.
Worker 135 12 Hours 1,301.04 Gh/s 13086208 <-The 387.5MHz one, device shows 1278GH/s
Worker 136 12 Hours 1,301.04 Gh/s 13086208 <-The 400MHz one, device shows 1319GH/s
I could see them matching up once, but having the exact same number of accepted shares twice in an hour seems extremely unlikely.
I think the S5 has a bug where it only sends up to N shares per period of time, which would explain this behaviour. |
|
|
|
I am develop a trading platform now, I must to compile the bitcoin source code by myself,
so, which version of the openssl I can use? Thanks. At this point, just use 0.9.4. my other question is, why the bitcoin system don't maintain one correct branch of openssl? Too large a codebase of mostly obfuscated spaghetti code. It's going to be replaced with libsecp256k1 (which we do maintain) "soon" (planned since before this issue). |
|
|
|
a) There would be absolutely no reason for a mining company to spend $2-8M on a chip run which has the sole purpose of bogging down a pool. It would be quite trivial for a chip that requires a secret code before it will find blocks... It could even only react once the timestamp is sufficiently far in the future - we've seen this before with optimised FPGA bitstreams (although they stopped finding any shares when the time hit). |
|
|
|
|
Show Posts
