[ANN] Stratum mining protocol - ASIC ready

[[Tycho]]

http://blog.bitcoin.cz/stratum is not found (404)

[BitcoinOxygen]

http://blog.bitcoin.cz/stratum is not found (404)

Try : http://mining.bitcoin.cz/stratum-mining

[[Tycho]]

http://blog.bitcoin.cz/stratum is not found (404)

Try : http://mining.bitcoin.cz/stratum-mining

I suppose it's not the same, since this page links to the first one at the bottom.

[flound1129]

Can anyone help with 2 stratum server configuration problems?


Stratum server reports this error when running without extended db support:

Code:

1054, "Unknown column 'difficulty' in 'field list'"

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:

Code:

ERROR protocol protocol.process_failure # [Failure instance: Traceback: <type 'exceptions.NameError'>: global name 'settings' is not defined

How can I fix this?  

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.

[flound1129]

for the second problem, add the following line at the top of interfaces.py with the other imports:

Code:

from stratum import settings

[nearmiss]

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..

Did new documentation or a community fork actually happen yet by chance?  Would be very interested in one!

[robotrebellion]

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?

[calonew]

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!

[DrHaribo]

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?

It seems some high hashrate users connecting to stratum are getting 100% rejects!

Never had that with my Stratum implementation. Which codebase is this?

[calonew]

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!

[biganth]

Anyone have any insight on this error when running the proxy?

Traceback (most recent call last):
  File "./mining_proxy.py", line 49, in <module>
    from stratum import settings
ImportError: No module named stratum

setup.py install seemed to go ok but there was a warning:

/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires'

Fixed:

Stupid me forgot to call install.

[tempt]

solved

[fuzzster]

I have been getting the following error whenever someone connects their miner:

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: <type 'exceptions.TypeError'>: 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
--- <exception caught here> ---
/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

[fuzzster]

On a separate note, has anyone else experienced the below error:

Code:

ERROR protocol # [Failure instance: Traceback: <class '_mysql_exceptions.OperationalError'>: (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?

[fuzzster]

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??

[DrHaribo]

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??

I don't think this is an issue with the Stratum protocol. You may have more luck asking in a thread that has to do with the specific software you are using.

But round_progress sounds wrong for bitcoin mining as there is no progress during the round.

[fuzzster]

Thanks for your reply DrHaribo. I'll post on the stratum-mining thread and see if anyone can shed some light.

I am just concerned I am wasting my hashes, and not sure if I should stop it and start again or keep it running with my fingers crossed...

At 106% now... 

[DrHaribo]

At 106% now... 

There is no progress in bitcoin mining. Mining is like a lottery. Each hash is a ticket. There is no way to know that "if I get 300 more lottery tickets then I will get a winning ticket for sure." Or "I lost playing the lottery every week for 10 years. That's a lot of progress. If I play for exactly 7 more weeks then I win the big jackpot."

I don't know which pool software you are running. But round progress doesn't exist.

[kano]

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??

'100%' is OF the statistical expected average of the random function of block mining.
If you get to 1,000,000 blocks you should find it close to average ...

[fuzzster]

Thanks for your replies!

It was me being paranoid - it found the block at 106