As I recall, BFGMiner validates the coinbase address to be a well-formed BITCOIN address, so if you are mining an alt coin, solo mining with GBT won't work. I'm not sure how you could validate the payout address in a way that would work for all possible alt coins. Not possible. GBT is only designed to work for Bitcoin. It's not merely validating the address, it's interpreting it. So there is no "just turn off validation", you'd need to implement support for the altcoin's address format. |
|
|
|
Can you pastebin a debuglog? Yes gimme a little while. Too slow  Try latest git, I think it's fixed. |
|
|
|
Lately I've been having weird issues with bfgminer mostly when the connection with eligius drops - if at some point the pool disconnects then after the reconnect or switch to another pool my miners just never start hashing again.
(...)
Try updating from git. I believe I just fixed this earlier tonight. Same thing still happening with 7bd2a8980979b087e4dc892dafe9534f4d6a7257 ... Can you upload a debuglog to dropbox or somewhere and send me a link? |
|
|
|
You are hereby notified that you are infringing on my copyright in this distribution. Under the license terms granted to you, you have 30 days to cure your non-compliance. You may review the license here: http://www.gnu.org/copyleft/gpl.htmlIf you do not follow the terms of the license within 30 days, I will need to take legal action against you. Thank you for your compliance, Luke P.S. Please note that I have no objection to your fee. You are free to make a profit, provided you abide by the license terms. |
|
|
|
Possible BUG:
Mining solo to bitcoind via GBT and having additional STRATUM pool for new block notifications does not work. The stratum thread is closed very soon with "Pool 1: Connection not needed, suspending" message.
Thanks. I've committed a probable fix for this issue in the main git branch. However, the fix is too invasive to be safe for older versions, so it won't be fixed in 3.10.1 or 3.5.8. |
|
|
|
I caught steal on some ASIC Blades V2... I don't think the Block Erupter Blades even pay for electricity anymore? :p After a day of research I finally discovered that although bfgminer supports ASIC Blades, it doesn't do so natively in the downloads I found, and needs to be compiled. Win32 version does support it. There is currently no way to build a Win64 version with support, due to limitations of libmicrohttpd. So, naturally I start working from the windows-build.txt being on a Win64 platform. Everything was going fine all the way down through every single step. Except for the last one. "./compile". Each time I removed every single download, reinstalled everything and walks through the steps, I would get stuck at:
checking whether HASH_ITER is declared... no
configure: error: Could not find HASH_ITER - please install uthash-dev 1.9.4+
Ok, so I backed up the latest version of utash-dev in the \include folder and finally found a 1.9.4 version and exported it there. still, no joy. Has anyone else come across this? If so, were you able to overcome the issue and how did you do it? Figure out where your uthash.h file is, and try ./configure CFLAGS='-I C:\path\with\uthash.h\inside\it' |
|
|
|
however, i noticed: out of the 64 chips total, 64 were recognized however only 60 were hashing/returning nonces. to rule out hardware state, i power cycled and tried again. same thing. to see if the Gen 2 detection was the culprit or something in between i did the following. git clone https://github.com/luke-jr/bfgminer bfgminer-nxt-2 && cd bfgminer-nxt-2
git checkout a355ac63b5671abd7a373151b683cd4e6be9ae2d //known solid, been running for months
git cherry-pick 9d647767620ef121452db7f1ebf1d6be524ea4d8 //added Rev.2 detection/
git cherry-pick 61a2b9aacb4ff779d8c5cd29c9eab3e346aeb8be //fixed hashrate reporting for Rev.2 chips
./autogen.sh
CFLAGS="-O2" ./configure --without-libusb --without-hidapi
make -j2
sudo ./bfgminer -o stratum.btcguild.com:3333 -O user:pass --set BFY:osc6_bits=55 --set BFY:baud=500000 this resulted in a version of my previous stable build with the addition of the Rev.2 detection and reporting. Lo and behold the same 4 chips that were not returning results before, were NOT returning results with this modified version of my stable. Can you pastebin a debuglog? |
|
|
|
the queue will only shrink due to payment limit shenanigans or manual payouts. Or transaction fees. Umm this is a official confirmation that the fees are not awarded to shares but used to pay and thus reduce the overall pending balances? Ah, no, you're right. I had forgotten wizkid057 changed that. |
|
|
|
the odds of hashing a block with positive luck is exactly 50% No, it's more like 63%. Because the longer-than-average time is unbounded. the queue will only shrink due to payment limit shenanigans or manual payouts. Or transaction fees. Also it is fun to note that in with the last 2 blocks the queue increased another 6BTC with "bad luck" Uh, bad luck shouldn't increase the queue length. |
|
|
|
Any volunteers to clean up after vandals? Particularly this one did a lot of spamming. Need someone(s) to sort through which of it is actual spam, which is legit, etc; and revert it as needed. Thanks |
|
|
|
I agree for bfgminer seems better hashrate ,it has reconnect issues though you have to restart if you got disconnected.
Those should be fixed in git as of a few days ago... |
|
|
|
is there a way to ask for a certain difficulty for workers?
In the old HHTT days I could add a _difficulty to my worker name to ask for that difficulty.
It seems to me there is not such an option, alas. BFGMiner has a --request-diff option to do this. Eligius (I think) still ignores it. It's also unnecessary.  |
|
|
|
damn I hope one day I can just drop that kind of money.
Nobody "dropped that kind of money"; it was the miners' property to begin with. |
|
|
|
Hi Luke, everyone,
Eloipool have what kind of attack, how to prevent?
The following information properly?
2014-05-10 19:48:50,568 StratumServer ERROR Traceback (most recent call last):
File "/home/tools/eloipool/networkserver.py", line 449, in serve_forever
o.handle_read()
File "/home/tools/eloipool/networkserver.py", line 62, in handle_read
self.handle_readbuf()
File "/home/tools/eloipool/networkserver.py", line 114, in handle_readbuf
self.found_terminator()
File "/home/tools/eloipool/stratumserver.py", line 60, in found_terminator
inbuf = b"".join(self.incoming).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0x87 in position 8: ordinal not in range(128)
2014-05-10 19:48:50,569 StratumHandler DEBUG Traceback (most recent call last):
File "/home/tools/eloipool/networkserver.py", line 449, in serve_forever
o.handle_read()
File "/home/tools/eloipool/networkserver.py", line 62, in handle_read
self.handle_readbuf()
File "/home/tools/eloipool/networkserver.py", line 114, in handle_readbuf
self.found_terminator()
File "/home/tools/eloipool/stratumserver.py", line 60, in found_terminator
inbuf = b"".join(self.incoming).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0x87 in position 8: ordinal not in range(128)
Shouldn't affect anything. |
|
|
|
With BFGminer in win7 how can i see the associated devices assigned com ports? I found the info 3 months ago and bookmarked it but that link is dead...  This was done via the command line.. TIA. bfgminer-rpc devdetails maybe? |
|
|
|
Lately I've been having weird issues with bfgminer mostly when the connection with eligius drops - if at some point the pool disconnects then after the reconnect or switch to another pool my miners just never start hashing again. Saw this in the log today: [2014-05-10 20:55:08] Accepted 04f7b06f NFY 1c pool 3 Diff 51/16
[2014-05-10 20:55:08] Accepted 0d3bef9f NFY 1a pool 3 Diff 19/16
[2014-05-10 20:55:08] Accepted 00380c0c NFY 1a pool 3 Diff 1.17k/16
[2014-05-10 20:55:08] Accepted 054b4b91 NFY 1d pool 3 Diff 48/16
[2014-05-10 20:56:08] Stratum connection to pool 3 interrupted
[2014-05-10 20:56:08] Pool 3 http://stratum.mining.eligius.st:3334 not responding!
[2014-05-10 20:56:08] Switching to pool 1 stratum+tcp://mint.bitminter.com:3333
[2014-05-10 20:56:08] pool 1 JSON stratum auth failed: [
20,
"Unknown method 'mining.get_transactions'",
null
]
[2014-05-10 20:56:08] Pool 1 stratum+tcp://mint.bitminter.com:3333 not responding!
[2014-05-10 20:56:08] Switching to pool 2 stratum+tcp://stratum.mining.eligius.st:3334
[2014-05-10 20:56:08] pool 1 JSON stratum auth failed: [
20,
"Unknown method 'mining.get_transactions'",
null
]
[2014-05-10 20:56:31] Pool 2 stratum+tcp://stratum.mining.eligius.st:3334 not responding!
[2014-05-10 20:56:39] Pool 1 stratum+tcp://mint.bitminter.com:3333 alive, testing stability
[2014-05-10 20:56:46] Switching to pool 1 stratum+tcp://mint.bitminter.com:3333
[2014-05-10 21:06:14] Stratum from pool 1 detected new block
[2014-05-10 21:17:22] Stratum from pool 1 detected new block
[2014-05-10 21:35:19] Stratum from pool 1 detected new block
[2014-05-10 21:36:36] Stratum from pool 1 detected new block
[2014-05-10 21:46:19] Stratum from pool 1 detected new block
[2014-05-10 21:59:46] Stratum from pool 1 detected new block
[2014-05-10 22:07:13] Stratum from pool 1 detected new block
for the record - I have the following pools: 0,2,3 - eligius, 1 - bitminter this was when running build: 3177195928193c7f744eee45885a3c3e1f8df49e-win32-gradual but it's been happening for a while (maybe last 1-2 months) Am I doing something possibly wrong? Or in the alternative - which debug logs/options should I turn on to get more details for further troubleshooting? Try updating from git. I believe I just fixed this earlier tonight. |
|
|
|
|
Bitcoin wallets have a Sign Message that proves who receives with an address.
Note that there is no functionality to prove who controls the private key associated to it, which often is a different person.
|
|
|
|
just recently did what i call a -next compile, from git source HEAD. the TLS support would NOT allow connecting to stratum.btcguild.com:3333 performed git revert 6520d158eba3bcff1b6e0343951ff38437ffea80 -m 1 to revert the merge then rebuilt. This allowed connection to the pool and hashing commenced. Did you wait a bit? BTCGuild is just hanging on TLS attempts, so there's a 30 second timeout when initially connecting and then later following the redirect. Eleuthria apparently does not plan to fix this, and I'm not sure whether it's worth removing (or requiring explicit enabling of) TLS just to workaround it. however, i noticed: out of the 64 chips total, 64 were recognized however only 60 were hashing/returning nonces. to rule out hardware state, i power cycled and tried again. same thing. to see if the Gen 2 detection was the culprit or something in between i did the following. git clone https://github.com/luke-jr/bfgminer bfgminer-nxt-2 && cd bfgminer-nxt-2
git checkout a355ac63b5671abd7a373151b683cd4e6be9ae2d //known solid, been running for months
git cherry-pick 9d647767620ef121452db7f1ebf1d6be524ea4d8 //added Rev.2 detection/
git cherry-pick 61a2b9aacb4ff779d8c5cd29c9eab3e346aeb8be //fixed hashrate reporting for Rev.2 chips
./autogen.sh
CFLAGS="-O2" ./configure --without-libusb --without-hidapi
make -j2
sudo ./bfgminer -o stratum.btcguild.com:3333 -O user:pass --set BFY:osc6_bits=55 --set BFY:baud=500000 this resulted in a version of my previous stable build with the addition of the Rev.2 detection and reporting. Lo and behold the same 4 chips that were not returning results before, were NOT returning results with this modified version of my stable. Can you get me a debuglog with --device-protocol-dump of this? Bonus: whats special about the new values in bitfury_init_chip payload? do they produce a hit on one of the additional cores in rev.2 chips? The new payload has 8 nonces in it, a few of which are never found by gen1 chips. ah. just wanted to make a note that on win7x64, bfgminer 32-bit the ramp up never occured. they stayed at 5 bits untill i manually changed them to 56. FWIW, I found the bug causing this. while (bitfury->osc6_bits < 50) On the first iteration, bitfury points to data beyond the array. |
|
|
|
|
Show Posts
