1. Build dependenciesThe README file mentions package names for dependencies, but in some cases I had to use different package names on Ubuntu 12.04:
- Instead of libncurses5-dev, I needed libncursesw5-dev.
- Instead of libusb-dev, I needed libusb-1.0-0-dev.
I don't know if those are errors or just a consequence of differences between distributions.
Either libncurses5 or libncursesw5 should be fine; I'm guessing you had the latter installed, which is why you needed a specific dev package. I'll update the README to mention both... as well as the libusb package name.
2. SSLI configured bitcoin-qt for SSL using a self-signed certificate as explained at
https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon, but bfgminer refused to connect due to the self-signed certificate. At first, I fixed it by disabling certificate verification:
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0);
Later, I copied the certificate from bitcoin-qt and told bfgminer to verify using that certificate. I also had to disable host name verification since I am connecting by IP address:
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0);
curl_easy_setopt(curl, CURLOPT_CAINFO, "bitcoin.cert");
Is there some standard way this is supposed to work that I'm missing? Maybe bfgminer needs settings to control these SSL behaviors.
SSL isn't really useful for mining, and doesn't quite interact well with BFGMiner in general.
It might seem to make sense for talking directly to a bitcoind, but bitcoind does not officially support exposing the JSON-RPC port to the internet (even with SSL), so I'm not sure this is a use case that should be encouraged.
3. getblocktemplate falling back to getwork
If I stop and restart bitcoin-qt while bfgminer is running, bfgminer detects that getblocktemplate failed and falls back to getwork from that point on. I fixed it by patching pool_protocol_fallback. There probably needs to be a way to force the use of getblocktemplate only.
Perhaps a --no-getwork option?
4. Long pollingbitcoin-qt does not support long polling, and by default bfgminer only calls getblocktemplate every 120 seconds, resulting in an average of 60 seconds of wasted work per block, or 10% of the total work. Without long polling, I'd prefer to call getblocktemplate more like every 5 seconds. I tried "--expiry 5" but found that it decreases the reported hash rate substantially. The GPU load is also significantly reduced, so the effect is real. I haven't tracked down exactly what effect the expiry setting is having, but it should be possible to make a new call to getblocktemplate while continuing to do work based on the result of the previous call. Or am I just not using the correct options?
I tried applying
pull request 1355 to add long polling support to my bitcoin-qt. It mostly works: hashing proceeds at full speed and new blocks are detected right away. The long polling implementation in the pull request is not ideal though. It only returns when a new block is found, not to update the set of transactions, so that means fewer transaction fees for the miner and slower transaction processing for everyone. It may be better for getblocktemplate to use the same logic for long polling that it uses to decide when to call CreateNewBlock: if a new block was received or if new transactions were received and at least 5 seconds have passed since the last update. I tried to simulate that by making getblocktemplate sleep for 5 seconds instead of waiting for a new block. It seemed to work, and didn't have a major impact on the hash rate. Trying to handle it on the client side with "--expiry-lp 5" had the same performance problems as "--expiry 5".
Another issue with the pull request: it prevents bitcoin-qt from shutting down promptly because the RPC thread is busy waiting for a new block.
I'll look into this... not sure on a good solution to the bitcoind LP pullreq issue :/
5. --coinbase-addr
The --coinbase-addr option uses a single address for all mined blocks. For privacy, it would be better for every block to use a distinct address. That would require the user to supply a pool of addresses to bfgminer, and bfgminer would need to mark them as "used" in a way that is persistent across sessions. I think it would be a nice enhancement.
Sounds like something for after I add persistent state to BFGMiner in the future. Could you open a GitHub issue so it's not forgotten?
