[ANN] Stratum mining protocol - ASIC ready

[Luke-Jr]

Anyone care to review mining.resume support for Eloipool? Also live on Eligius ( stratum+tcp://mining.eligius.st:3334 ) for direct testing..

[1714009228]

1714009228

[1714009228]

1714009228

[1714009228]

1714009228

[-ck]

miner will call mining.resume('session-id') instead of mining.subscribe(...).

Also can you elaborate on the exact format of mining.subscribe with an example please? I'll inevitably get it wrong if I don't see a sample.

[slush]

If mining.resume is successful, does this mean the miner does not need to do mining.authorize afterwards?

Yes. If pool returns true for the call, it means the connection can continue like if it wasn't interrupted (so no authorization is needed).

This is current response of mining.subscribe():

Code:

{"id": 1, "result": [[], "08000002", 4], "error": null}\n

This is response containing session id:

Code:

{"id": 1, "result": [[], "08000002", 4, "some-session-id"], "error": null}\n

This is also valid response of the server, but no session id is given, so no resume is available:

Code:

{"id": 1, "result": [[], "08000002", 4, null], "error": null}\n

[-ck]

If mining.resume is successful, does this mean the miner does not need to do mining.authorize afterwards?

Yes. If pool returns true for the call, it means the connection can continue like if it wasn't interrupted (so no authorization is needed).

This is current response of mining.subscribe():

Code:

{"id": 1, "result": [[], "08000002", 4], "error": null}\n

This is response containing session id:

Code:

{"id": 1, "result": [[], "08000002", 4, "some-session-id"], "error": null}\n

This is also valid response of the server, but no session id is given, so no resume is available:

Code:

{"id": 1, "result": [[], "08000002", 4, null], "error": null}\n

Thanks.

In the preliminary support in rEligius, wizkid tells me they still expect mining.authorize after mining.resume, and then they sent a new session-id which seems counterintuitive to me?

Code:

 [2013-02-15 22:03:25] SEND: {"id": 2, "method": "mining.resume", "params": ["08000000"]}                    
 [2013-02-15 22:03:26] RECVD: {"result": true, "id": 2, "error": null}                    
 [2013-02-15 22:03:26] Resumed stratum connection to pool 0                    
 [2013-02-15 22:03:26] SEND: {"id": 3, "method": "mining.subscribe", "params": []}                    
 [2013-02-15 22:03:26] RECVD: {"result": [[["mining.notify", "090000001"], ["mining.set_difficulty", "090000002"]], "09000000", 4, "09000000"], "id": 3, "error": null}          

I would have expected that mining.resume is enough without needing authorise, and then there would be no new mining.notify, and the sessionid would be the same.

Are there any security implications with allowing a miner to reconnect without re-authorising? I can't think of anything significant.

[slush]

Why are you sending mining.subscribe after mining.resume??

I don't think there's any security issue. If the "attacker" knows the session id, then he obviously also known passwords used by workers for authentication.

[-ck]

Why are you sending mining.subscribe after mining.resume??

I don't think there's any security issue. If the "attacker" knows the session id, then he obviously also known passwords used by workers for authentication.

My mistake about redoing mining-subscribe. Fixed in git.

I will await to see what others have to say about needing to re-authorise since the only implementation currently does expect it.

[Luke-Jr]

Without mining.authorize, it would be easy for someone to hijack a session just by guessing its session id.

I'd actually prefer requiring mining.authorize before a resume, since that would enable disconnecting a prior (dead?) connection.
Right now, mining.resume will fail if a connection is still using the session id...

[slush]

Without mining.authorize, it would be easy for someone to hijack a session just by guessing its session id.

That's the matter of implementation. Put some hash into the session id and you're safe.

Right now, mining.resume will fail if a connection is still using the session id

This also depends on implementation. You can forcibly close all other connections once some connection tries to resume with the same session id.

[-ck]

Well, an extra authorise request is no big deal, so for the moment, that's how I've implemented it in cgminer. So most of the mining.resume support is now in the master git branch for cgminer.

[zvs]

Stratum seems to cause a lot of problems w/ my systems with crappy CPU and 4+ GPUs....  they jump between 95-99% activity, and I can visibly see cursor jumping around... doesn't happen with longpolling

is there something that would help w/ this?  i've already tried turning off DCA and killed off all but the 5 or 6 essential services (all run windows)

ed: i'm speaking of p2pool only in regard to long poll vs stratum.  p2pool has a lot more stratum requests than a normal pool would, i guess

[slush]

is there something that would help w/ this?  i've already tried turning off DCA and killed off all but the 5 or 6 essential services (all run windows)

What miner are you using? Basically there's no reason for issues like this just because of switching from getwork to stratum...

[zvs]

is there something that would help w/ this?  i've already tried turning off DCA and killed off all but the 5 or 6 essential services (all run windows)

What miner are you using? Basically there's no reason for issues like this just because of switching from getwork to stratum...

cgminer, with intensity all at 7...  it possibly wouldnt occur on something other than p2pool. 

but i have used p2pool w/ both stratum & without and i don't get the short freezes when not using it.   

hmm, would nagle being disabled have some effect more on stratum than on getwork?

[zvs]

OK, I made 3 screenshots, ignore all the core clocks and stuff that afterburner is showing (i only use it for temperature/usage monitoring and sometimes voltage).. the one computer is using catalyst 11.12 because of 5 gpu.  

i would have taken a screenshot of a computer similar to the 3rd (that is using catalyst 12.1) that showed GPU bumping around but i have all usb slots disabled in bios on that one and didnt want to reboot it... it's using catalyst 12.1 with crappy sempron and 3 gpu

the first, the GPU usage dipped just a little bit (where it has that big drop, that was just me doing something)..  that is on a dual core 3.2ghz (underclocked to 2.0ghz or so but didnt disable a core)


 
(^^ ed: I just looked at that more closely and not sure wtf happened there at the end, with the restart being overwritten)

the second, this is my main computer, i7 etc



the third, this is a Sempron, 3ghz?  maybe 3.2ghz...  the drops seem to coincide with the stratum restarts (the "somewhat" flat period was the 20 seconds or so with no restarts)



all intensities are at 7, and, yes, i get a lot of rejects (this is common to both, so nothing about stratum there).. 180ms to server, but better than using my home connection that has no upstream bandwidth

[BitcoinOxygen]

Anyone care to review mining.resume support for Eloipool? Also live on Eligius ( stratum+tcp://mining.eligius.st:3334 ) for direct testing..

It would be nice if you could add some comments to your code.

[Luke-Jr]

Regarding mining.resume...
The proposed mining.resume protocol breaks stratum proxy, and cgminer's implementation is full of bugs, so I've decided to put off merging it to Eloipool master for now pending some kind of revision to deal with these bugs.

Regarding client.get_version...
Sadly, I've also found I cannot simply disable it based on client.get_version response - apparently requesting this information before initialization has completed breaks cgminer.
The only solution I can think of to deal with this bug is to have newer clients send their version unsolicited before trying to subscribe.

Regarding a default difficulty request...
Another feature request (which I have to note has been specified in GBT for a year now) is the ability for miners to send a default difficulty/target to the server.
Since clients are subscribing before authorizing, there's no reliable way to abuse to username/password for this purpose.
I propose clients simply send a mining.set_difficulty to the server when they connect, before subscribing, and adopt it only if the server replies with a true result.

Thoughts on any of these?

[eleuthria]

Regarding mining.resume...
The proposed mining.resume protocol breaks stratum proxy, and cgminer's implementation is full of bugs, so I've decided to put off merging it to Eloipool master for now pending some kind of revision to deal with these bugs.

Regarding client.get_version...
Sadly, I've also found I cannot simply disable it based on client.get_version response - apparently requesting this information before initialization has completed breaks cgminer.
The only solution I can think of to deal with this bug is to have newer clients send their version unsolicited before trying to subscribe.

Regarding a default difficulty request...
Another feature request (which I have to note has been specified in GBT for a year now) is the ability for miners to send a default difficulty/target to the server.
Since clients are subscribing before authorizing, there's no reliable way to abuse to username/password for this purpose.
I propose clients simply send a mining.set_difficulty to the server when they connect, before subscribing, and adopt it only if the server replies with a true result.

Thoughts on any of these?

I've felt that the client should send their name/version unsolicited with the initial subscription from the start.  It makes sense for the client to push that data, rather than the server to ask for it explicitly.  It's just a few bytes sent once.

[jborkl]

Luke, I thought you were still using this full of bugs codebase.....?

Luke , have you submitted a support ticket to Con, so he can help you out?

User defined Stratum diff is already available. So I don't see the rush to implement it into a miner.

[-ck]

Luke, I thought you were still using this full of bugs codebase.....?

Luke , have you submitted a support ticket to Con, so he can help you out?

He submitted 2 bugfixes, I took them. After that... no idea, but then I go out of my way to make myself uncontactable by him, but somehow he still gets through. I'm in a quandary here if I'm to fix bugs he reports but I don't give him a way to report them apart from random attacks on the codebase in the forum as quoted by someone else. If he could stop with the mindless attacks and other crap, I'd listen and he'd have a way, but I can't sift through his noise because it really is a mindfuck.

I really should give up, this is doing my head in.

[Luke-Jr]

Luke, I thought you were still using this full of bugs codebase.....?

Fixing bugs as I find them, but Eloipool still has to support cgminer for now.

Luke , have you submitted a support ticket to Con, so he can help you out?

Feel free to pass it on to him. The details on the mining.resume bug lie in send() succeeding even when the packets don't actually reach their destination, and cgminer leaking the sshare object since it never gets a response.
BFGMiner's codebase is too different from cgminer's in the relevant code, so if this gets fixed it can be the first cgminer-unique feature until I get a chance to write a version for BFGMiner.

[nathanrees19]

cgminer's implementation is

This unjustified assertion has no place in this thread.

Sadly, I've also found I cannot simply disable it based on client.get_version response - apparently requesting this information before initialization has completed breaks

It's normal for things to break if you hammer them with requests before initialization is finished.

The only solution I can think of to deal with this bug is to have newer clients send their version unsolicited before trying to subscribe.

This is surprisingly not a bad idea.

Another feature request (which I have to note has been specified in GBT for a year now)

There's no need to beat a dead horse here.

is the ability for miners to send a default difficulty/target to the server.

It should be up to the server to decide what rate of shares it can accept, but if an unsolicited client version is to be added, then perhaps a "suggested minimum difficulty" could be added as well.