-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stratum support #24
Comments
I started working on this a few days ago. |
Wow, sounds awesome 👍 |
This would be useful. The new altcoins can often be cpu mined at first launch while the difficulty is low, but when the difficulty is low, pooled mining needs to be stratum because the blocks are found so quickly. If you need someone to test this on CentOS or Ubuntu, let me know. Otherwise, I'm not sure how helpful I would be. |
Stratum support added in commit ee7b535. |
The X-Stratum header parsing seems to not quite work. It seems to detect the header okay, but doesn't redo the request, and fails with a "JSON decode failed(1): '[' or '{' expected near 'Stratum'" error. Connecting with stratum+tcp:// works, though, it has some trouble with the target. The problem seems to be because my pool sends the mining.set_difficulty command after the initial params, and cpuminer only updates the target when parsing a params command (util.c:1050). So from connect until the first new block arrives the target is wrong, and most shares fail with: Changing stratum_set_difficulty() to set sctx->job.diff in addition to next_diff seems to work, though I'm guessing that has some race condition you were trying to avoid with the two-step thing. Increasing the default timeout from 120s was also helpful, as my system isn't fast enough to reliably crunch a share in that time, and it kept reconnecting. 😄 Testing with the Coinotron.com pool. |
@Maeyanie Second issue: This looks like a bug in the pool's implementation of Stratum. According to the specifications (see here and here), miners should only begin enforcing the new difficulty on the next job received. I have talked to the operator of Coinotron and he said he's going to fix this soon. Third Issue: This is more delicate. The specifications state that mining.notify messages should be sent by the server at regular intervals, but do not set an upper limit to the time a miner can go without fresh work. That said, all the pools I had tested send at least a notification every minute, which makes sense, because this way new transactions can get included in the next block. This is why if minerd doesn't receive any communication from the pool for two minutes it considers the connection dead and tries to reconnect. I think cgminer does the same. |
Ah, figures I happen to test it on a broken pool. 😉 It did seem to work fine both with your miner before Stratum, and with cgminer, though. Maybe I was just testing with a different coin type. Besides, I guess testing with slightly-bad input is the best way to find potential problems anyhow. 😄 It does seem fairly safe to increase the timeout, though, since I noticed you use TCP keepalives to detect if the connection dies. |
No description provided.
The text was updated successfully, but these errors were encountered: