BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked. I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise. Only blind stratum uses less bandwidth. Secured stratum uses more, since it doesn't support compression. While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse. Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment? So I was right. At this time, choosing GBT over Stratum is just wasting bandwidth, with no tangible advantages in the here and now. Sure, it has potential, but until that potential turns into an actual increase in network security, you can't really complain about pools not choosing GBT, can you? It's already actual, since pools can't know who is or isn't verifying what. |
|
|
|
These numbers aren't relevant in any meaningful way.
If your concern is shares, look at the 3rd hashrate
If your concern is bandwidth, look at E: (higher is better) Bandwidth is not a problem for me. And I notice a problem because the bitminter java client produces a lot of shares for the same hashrate than bfgminer (~5× more). Same problem with bfgminer in load-balance mode, 50btc and bitcoin.cz produces 4× more shares than bitminter for the same number of work request and hashrate. Is it possible BitMinter is vardiff and the others are not? Pretty normal for stratum pools. bitcoin.cz is stratum too, and no such « work restart » on it… That would be very odd.. are you sure you're connecting to it with stratum? Maybe the messages are just not as noticable since you're finding more shares between them? You can use --no-stratum to avoid it. Stratum is the new bitcoin way for mining, why avoid it  Some pool give you more payback when you use stratum instead of gwork, like bitcoin.cz. The community-developed standard ("new bitcoin way") is getblocktemplate (GBT). Stratum supports less functionality, was developed behind closed doors, and uses more bandwidth than GBT unless used in a way harmful to Bitcoin. While it might with time become a new standard (slush recently started bringing it to the BIP standardization process), it still has a way to go before it can really compete with GBT. Admittedly, knowing this doesn't do much for you while you mine on pools that force you to use stratum because they refuse to support standard GBT, but that is not the case with BitMinter  |
|
|
|
BitMinter does support GBT, which is better - not sure why they keep switching people to stratum.
Your own comparison between GBT and Stratum shows Stratum using a fraction of the bandwidth. Any potential advantages of having a miner automatically download a copy of the transaction list is completely unused by every miner software out here, including yours, last time I checked. I know GBT is your favorite, and that's fine, but please don't make universal statements like "GBT is better" when the evidence proves otherwise. Only blind stratum uses less bandwidth. Secured stratum uses more, since it doesn't support compression. While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse. Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment? |
|
|
|
[quote author=aeris link=topic=78192.msg1553650#msg1553650 date=1361648097]I have some trouble with bfgminer on bitminter pool.
I have a very low shares production compare to bfgminer on other pools:
- bitminter : 656 Work Request, 4 Shares -> 6‰
- 50btc : 761 Work Request, 20 Shares -> 26‰
- bitcoin.cz : 1513 Work Request, 43 Shares -> 28‰[/quote]These numbers aren't relevant in any meaningful way.
If your concern is shares, look at the 3rd hashrate
If your concern is bandwidth, look at E: (higher is better) On log, I see a lot of « Stratum from pool 0 requested work restart » for bitminter, and no such trace on other pools: [2013-02-23 20:22:04] Stratum from pool 0 requested work restart
[2013-02-23 20:22:36] Stratum from pool 0 requested work restart
[2013-02-23 20:23:07] Stratum from pool 0 requested work restart
[2013-02-23 20:23:38] Stratum from pool 0 requested work restart
[2013-02-23 20:24:09] Stratum from pool 0 requested work restart
[2013-02-23 20:24:40] Stratum from pool 0 requested work restart
[2013-02-23 20:25:11] Stratum from pool 0 requested work restart
[2013-02-23 20:25:43] Stratum from pool 0 requested work restart
[2013-02-23 20:26:14] Stratum from pool 0 requested work restart
[2013-02-23 20:26:45] Stratum from pool 0 requested work restart
[2013-02-23 20:27:16] Stratum from pool 0 requested work restart After activate debug, seems each work restart occurs just after a get_transactions, which is an unknown method on bitminter : [2013-02-23 20:31:57] Unknown stratum msg: {"error": [-3, "Method 'get_transactions' not found for service 'mining'", null], "id": "txlist19ea", "result": null}
[2013-02-23 20:31:58] Work stale due to work restart (32 != 33)
[2013-02-23 20:31:58] Popping work from get queue to get workPretty normal for stratum pools. You can use --no-stratum to avoid it. BitMinter does support GBT, which is better - not sure why they keep switching people to stratum. |
|
|
|
2013-02-23 14:04:49,958 merkleMaker INFO New block: 00000000000002323fa1359645f9c26ec005792f9d463faa55931f32cde12020 (height: 222693; bits: 1a04985c)
2013-02-23 14:04:50,111 JSONRPCServer INFO Longpoll woke up 6 clients in 0.042 seconds
2013-02-23 14:04:50,126 merkleMaker CRITICAL Traceback (most recent call last):
File "/home/xxxxxx/merklemaker.py", line 680, in run
self.merkleMaker_I()
File "/home/xxxxx/merklemaker.py", line 670, in merkleMaker_I
self.merkleMaker_II()
File "/home/xxxxx/merklemaker.py", line 648, in merkleMaker_II
return self._updateMerkleTree()
File "/home/xxxxx/merklemaker.py", line 536, in _updateMerkleTree
self._updateMerkleTree_I()
File "/home/xxxxx/merklemaker.py", line 506, in _updateMerkleTree_I
r = self._updateMerkleTree_fromTS(TS)
File "/home/xxx/merklemaker.py", line 485, in _updateMerkleTree_fromTS
AcceptRatio = AcceptedScore / TotalScore
ZeroDivisionError: int division or modulo by zero
Fixed in git. 2013-02-23 16:14:17,978 JSONRPCHandler ERROR Error during JSON-RPC call (UA=b'cgminer 2.10.2', IP=::ffff:xx.xx.41.73): doJSON_submitblock['02000000d6b2ca723dd01ffffffff025d5988ac00000000', {}]
Traceback (most recent call last):
File "/home/xxxx/jsonrpcserver.py", line 200, in _doJSON_i
rv = getattr(self, method)(*params)
File "/home/xxxxx/jsonrpc_getblocktemplate.py", line 91, in doJSON_submitblock
data = bytes.fromhex(data)
ValueError: non-hexadecimal number found in fromhex() arg at position 166 i think it is bug in cgminer 2.10.2 ? Yep. 2013-02-23 16:29:37,753 JSONRPCServer INFO Longpoll woke up 2 clients in 0.272 seconds
2013-02-23 16:30:45,122 merkleMaker ERROR Upstream 'primary' rejected proposed block from 'primary': stale-prevblk
2013-02-23 16:30:45,132 merkleMaker CRITICAL Traceback (most recent call last):
File "/home/xxxx/merklemaker.py", line 680, in run
self.merkleMaker_I()
File "/home/xxxxx/merklemaker.py", line 670, in merkleMaker_I
self.merkleMaker_II()
File "/home/xxxxx/merklemaker.py", line 648, in merkleMaker_II
return self._updateMerkleTree()
File "/home/xxxxxx/merklemaker.py", line 536, in _updateMerkleTree
self._updateMerkleTree_I()
File "/home/xxxx/merklemaker.py", line 522, in _updateMerkleTree_I
raise RuntimeError('Failed to create usable template')
RuntimeError: Failed to create usable template
Happens sometimes. bitcoind has found a new block, so is reporting our proposal stale. I'm assuming it's followed very quickly with a new block notification? 2013-02-23 14:33:47,374 merkleMaker WARNING Transaction-longpoll requested 22 seconds ago, and still not ready. Is your server fast enough to keep up with your configured WorkQueueSizeRegular maximum? (doing longpoll merkle roots)
2013-02-23 14:33:47,374 merkleMaker WARNING Haven't updated the merkle tree in at least 22 seconds! Is your server fast enough to keep up with your configured work queue minimums? (doing longpoll merkle roots)
2013-02-23 14:33:49,320 JSONRPCServer INFO Nobody to longpoll
2013-02-23 14:34:26,101 StratumServer ERROR Traceback (most recent call last):
File "/home/yyyyyyy/networkserver.py", line 413, in serve_forever
o.handle_read()
File "/home/yyyyy/networkserver.py", line 59, in handle_read
self.handle_readbuf()
File "/homeyyyyy/networkserver.py", line 111, in handle_readbuf
self.found_terminator()
File "/home/yyyyyy/stratumserver.py", line 60, in found_terminator
inbuf = b"".join(self.incoming).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xb9 in position 32: ordinal not in range(128) Sounds like bad data sent to the server. |
|
|
|
It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity.
I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it.
Appreciated, thanks. It doesn't take long for me to run into this state (no more than a few hours at most) so I will, at the very least, be able to see if your fix improves the situation quickly enough. If you can test 2.99.0, that does include this change. |
|
|
|
|
Since they don't seem to have posted here on their own accord, a number of bASIC customers have popped into the IRC channel to report having received their Bitcoin refunds.
|
|
|
|
I've uploaded some prerelease/alpha Windows builds of BFGMiner 3.0 for testing. While they do support BitForce SC ASICs, this is completely untested so far (obviously). There has been some major restructuring involved, so 3.0 will work differently both under and over the hood for FPGAs, especially BitForce and X6500 which have been ported to take advantage of the new device API. 37 files changed, 4325 insertions(+), 2993 deletions(-) Please verify your FPGAs/GPUs/pools/etc still work as expected. Note the new --show-processors option to view your FPGAs at a more detailed level. |
|
|
|
It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity. I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it. |
|
|
|
that is true, a have add commas, and now i get this error >>> 2013-02-22 22:53:35,380 merkleMaker INFO New block: 00000000000004509071260531df744090422d372d706cee907b2b5f2be8b8ff (height: 222598; bits: 1a04985c)
2013-02-22 22:53:35,382 JSONRPCServer INFO Waiting 14.1 seconds to longpoll
2013-02-22 22:53:35,450 merkleMaker CRITICAL Traceback (most recent call last):
File "/home/xxx/merklemaker.py", line 680, in run
self.merkleMaker_I()
File "/home/xxx/merklemaker.py", line 670, in merkleMaker_I
self.merkleMaker_II()
File "/home/xxx/merklemaker.py", line 636, in merkleMaker_II
return self._updateMerkleTree()
File "/home/xxx/merklemaker.py", line 536, in _updateMerkleTree
self._updateMerkleTree_I()
File "/home/xxx/merklemaker.py", line 506, in _updateMerkleTree_I
r = self._updateMerkleTree_fromTS(TS)
File "/home/xxx/merklemaker.py", line 481, in _updateMerkleTree_fromTS
(AcceptedScore, TotalScore) = self._CheckTemplate(newMerkleTree, TS)
File "/home/xxx/merklemaker.py", line 430, in _CheckTemplate
propose = caccess.getblocktemplate(ProposeReq)
File "/home/xxx/jsonrpc/authproxy.py", line 106, in __call__
raise JSONRPCException(resp['error'])
jsonrpc.authproxy.JSONRPCException Probably your bitcoind is missing BIP 23 Proposal support. There is a pull request for bitcoind here. It's also included in the 0.6.0.eligius and 0.8.0.eligius miner releases of bitcoind. Alternatively, it should be safe to use Eloipool without any TemplateChecks. This is only used to guard against unknown bugs in block creation. |
|
|
|
Had to restart the miner at uptime 1 day, 21 hours. cgminer was responding, but no mining work was going upstream to the pool. The 'hardware errors' count was increasing rapidly. Just cgminer? Or all of OpenWrt? Or the entire machine? |
|
|
|
Hey Inaba,
Since Stratum has a new mining.resume function I was wondering. Do you know how difficult it would be to add it?
It would save shares on disconnects so that would be a plus.
Thank You for all your hard work! slush, Eleu, conman, and I discussed mining.resume on IRC the other day, and decided to replace it with a different resume mechanism. I'll work on an Eloipool implementation after getting through the BFL SC support in BFGMiner, and sometime after that a BFGMiner implementation to use it. |
|
|
|
this error still appears , just after starting the program, >>> Traceback (most recent call last):
File "./eloipool.py", line 909, in <module>
MM.start()
File "/home/xxxxxxxx/merklemaker.py", line 685, in start
self._prepare()
File "/home/xxxxxxxx7/merklemaker.py", line 117, in _prepare
URINamePair(TS, 'TemplateSources[%u]' % (i,))
File "/home/xxxxxxxx/merklemaker.py", line 104, in URINamePair
a['name'] = URI2Name.get(a['uri'], defname)
TypeError: string indices must be integers
and the program stops i send config.py to PM (pastebin ) is it a problem with configuration ? i use the same settings in the previous version . Check that all your option lists (especially TemplateSources, TemplateChecks, and BlockSubmissions) have commas after every element (including the last!). |
|
|
|
Running 2.10.5 under Win7/64, my Singles occasionally get into a WAIT state in which they stop hashing or submitting shares. The software is still running because I can see the regular messages appear (longpoll detected, requested work restart, etc.), but the Singles don't seem to get out of WAIT unless I manually switch pools via the (p)(s) command. I've had this happen when mining on bitminter and eclipse, using Stratum as well as the regular vardiff/LP ... so there doesn't seem to be a common theme.
Anecdotally I started encountering this sometime after Stratum support was added (several months ago); it has happened in all of the past few versions since then. I seem to be able to avoid the WAIT state by using the --no-stratum flag. But since I'm not hearing of anyone else having this issue, I'm sure it must be something unique to my setup ... but I have 3 separate clusters running off 3 separate PCs and I've seen the WAIT behavior on all of them.
I have several backup pools configured, and I'm wondering why bfgminer doesn't switch automatically to one of the backup pools instead of putting the miners into a WAIT state. Or is there a way to configure it to do this (I don't see anything obvious in the readme, but perhaps I missed something). The only change --no-stratum makes is disabling automatic switching from GBT/getwork to stratum. If it works with that option, this means your problem is stratum-specific. A debug log of this occurring would help: bfgminer YOUR OPTIONS FIRST --debuglog 2>debug.log Failover is currently still managed by code inherited from cgminer, which is rather slow to react to problems. I plan to rewrite it eventually, but haven't got around to that yet. |
|
|
|
|
rKUGcaxLUkC6H1hUm8mGo4DnsQFc35Ew16
|
|
|
|
Please include it in 0.8.1 *exactly like this*  IMO, this is definitely a 0.9 feature at the earliest. Way too big a change for 0.8.x |
|
|
|
When I start ./eloipool.py I get the error that the jsonrpc module isn't found. That means the bitcoinrpc module isn't installed correctly. |
|
|
|
Please open a pullreq for this after rebasing to 0.8. |
|
|
|
Ok, i'm trying to get eloipool with litecoin, and i'm getting this error:
python eloipool.py
Traceback (most recent call last):
File "eloipool.py", line 43, in <module>
bcnode = BitcoinNode(config.UpstreamNetworkId)
File "/home/pi/eloipool/bitcoin/node.py", line 132, in __init__
super().__init__(*a, **ka)
TypeError: super() takes at least 1 argument (0 given) How did you fix this? I am getting the same error. Thanks. Eloipool doesn't support scamcoins like Litecoin. If you're still getting the error anyway, it looks like it's probably from some ancient version of Python. As the README clearly states, you need Python 3. To be more specific, I test under 3.1. |
|
|
|
|
Show Posts
