The round_progress has gone to 104%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
Topic: [ANN] Stratum mining protocol - ASIC ready - page 6. (Read 146229 times)
I have managed to solve my error above! One more thing...
The round_progress has gone to 104%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
The round_progress has gone to 104%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
On a separate note, has anyone else experienced the below error:
I've noticed people on other forums have had it, but no one seems to have a solution!
Any ideas?
Code:
ERROR protocol # [Failure instance: Traceback:: (2006, 'MySQL server has gone away')
I've noticed people on other forums have had it, but no one seems to have a solution!
Any ideas?
I have been getting the following error whenever someone connects their miner:
Although the mining seems to continue fine, it was a massive annoyance, without mentioning the additional logging mess it made. After much digging, the culprit turns out to be when the mining.subscribe method is called from protocol.py, Stratum didn't like the additional parameter being used (in my case CGMiner/3.1.0 or something similar) in msg_params.
As such, I have created a work around by adding some code directly after the following lines in protocol.py:
The code being:
This removes the error and everything SEEMS to be mining OK, however I was wondering peoples thoughts on it as it was just a hack. Could it effect anything down the line?
Unfortunately my Python is very poor, so please be nice with your comments
Code:
2013-05-23 08:29:18+0000 [Protocol,0,141.0.48.3]
2013-05-23 08:29:18,619 ERROR protocol # [Failure instance: Traceback:: subscribe() takes exactly 1 argument (2 given)
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:192:dataReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:246:lineReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:13:_handle_event
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:81:call
------
/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py:137:maybeDeferred
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:78:_run
Although the mining seems to continue fine, it was a massive annoyance, without mentioning the additional logging mess it made. After much digging, the culprit turns out to be when the mining.subscribe method is called from protocol.py, Stratum didn't like the additional parameter being used (in my case CGMiner/3.1.0 or something similar) in msg_params.
As such, I have created a work around by adding some code directly after the following lines in protocol.py:
Code:
msg_id = message.get('id', 0)
msg_method = message.get('method')
msg_params = message.get('params')
msg_result = message.get('result')
msg_error = message.get('error')
The code being:
Code:
if msg_method == "mining.subscribe":
del msg_params[0:len(msg_params)]
This removes the error and everything SEEMS to be mining OK, however I was wondering peoples thoughts on it as it was just a hack. Could it effect anything down the line?
Unfortunately my Python is very poor, so please be nice with your comments
solved
Anyone have any insight on this error when running the proxy?
setup.py install seemed to go ok but there was a warning:
Fixed:
Stupid me forgot to call install.
Quote
Traceback (most recent call last):
File "./mining_proxy.py", line 49, in
from stratum import settings
ImportError: No module named stratum
File "./mining_proxy.py", line 49, in
from stratum import settings
ImportError: No module named stratum
setup.py install seemed to go ok but there was a warning:
Quote
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires'
Fixed:
Stupid me forgot to call install.
Never had that with my Stratum implementation. Which codebase is this?
It seems the reason of the 100% rejects was not our server's fault. Those 2 users were wrongly using --scrypt miners for a SHA-256 chain
So... that was the reason of their 100% rejects!
Does anyone know when it is safe to send a client.get_version request from the server to the client?
Some miner clients seem to interpret it as a response to their auth request and see it as auth failing.
Since clients can send auth requests at any time this means it is never safe to send a request from server to client?
Never had that with my Stratum implementation. Which codebase is this?
Some miner clients seem to interpret it as a response to their auth request and see it as auth failing.
Since clients can send auth requests at any time this means it is never safe to send a request from server to client?
It seems some high hashrate users connecting to stratum are getting 100% rejects!
Never had that with my Stratum implementation. Which codebase is this?
It seems some high hashrate users connecting to stratum are getting 100% rejects!
This happens for 2 users until now: one with 32,000 MH/s and one with 42,000 MH/s
Both users got 100% rejects. No share was accepted. The difficulty was variable, adjusted by stratum automatically.
Can anyone suggest a fix to this problem?
EDIT
It seems this was the users's fault... The reason of those 100% rejects was the wrong use of --scrypt miners for a SHA-256 chain!
This happens for 2 users until now: one with 32,000 MH/s and one with 42,000 MH/s
Both users got 100% rejects. No share was accepted. The difficulty was variable, adjusted by stratum automatically.
EDIT
It seems this was the users's fault... The reason of those 100% rejects was the wrong use of --scrypt miners for a SHA-256 chain!
Code:
# ******************** BASIC SETTINGS ***************
# These are the MUST BE SET parameters!
CENTRAL_WALLET = 'set_valid_addresss_in_config!' # local bitcoin address where money goes
BITCOIN_TRUSTED_HOST = 'localhost'
BITCOIN_TRUSTED_PORT = 8332
BITCOIN_TRUSTED_USER = 'user'
BITCOIN_TRUSTED_PASSWORD = 'somepassword'
# ******************** BASIC SETTINGS ***************
# Backup Bitcoind connections (consider having at least 1 backup)
# You can have up to 99
#BITCOIN_TRUSTED_HOST_1 = 'localhost'
#BITCOIN_TRUSTED_PORT_1 = 8332
#BITCOIN_TRUSTED_USER_1 = 'user'
#BITCOIN_TRUSTED_PASSWORD_1 = 'somepassword'
#BITCOIN_TRUSTED_HOST_2 = 'localhost'
#BITCOIN_TRUSTED_PORT_2 = 8332
#BITCOIN_TRUSTED_USER_2 = 'user'
#BITCOIN_TRUSTED_PASSWORD_2 = 'somepassword'
What happens if a Backup Bitcoind connection submits a block that gets accepted?
Does the block reward still go to the CENTRAL WALLET?
Ok, we have it working, we know how to adjust share diffiiculty, it's all good...
We will be uploading our fork with new documentation for the community later..
We will be uploading our fork with new documentation for the community later..
Did new documentation or a community fork actually happen yet by chance? Would be very interested in one!
for the second problem, add the following line at the top of interfaces.py with the other imports:
Code:
from stratum import settings
Can anyone help with 2 stratum server configuration problems?
Stratum server reports this error when running without extended db support:
Any ideea of how can I prevent this?
Also, when trying to disable variable difficulty (VARIABLE_DIFF = False) in config.py, the server reports this error:
How can I fix this?
Stratum server reports this error when running without extended db support:
Code:
1054, "Unknown column 'difficulty' in 'field list'"
Also, when trying to disable variable difficulty (VARIABLE_DIFF = False) in config.py, the server reports this error:
Code:
ERROR protocol protocol.process_failure # [Failure instance: Traceback:: global name 'settings' is not defined
Run with extended DB support if you want to use vardiff. Otherwise you won't be able to record the difficulty of the shares people are submitting and you won't be able to calculate payments correctly.
I suppose it's not the same, since this page links to the first one at the bottom.
http://blog.bitcoin.cz/stratum is not found (404)
More information might be handy?
Transactions from where? and on what?
When I tried the mysql option in generalfaults stratum-mining seemed to be working.
Transactions from where? and on what?
When I tried the mysql option in generalfaults stratum-mining seemed to be working.
Which one stratum or stratum-mining?
I'm not able to do any MySQL transactions while this is running, everything hangs on BEGIN unless I shut the server down.. Has any progress been made on the MySQL support?
Hello guys,
Are there any public stratum enabled server implementation for scrypt (litecoin)? Or perhaps someone could sell patch for scrypt support?
Are there any public stratum enabled server implementation for scrypt (litecoin)? Or perhaps someone could sell patch for scrypt support?
Jump to: