[ANN] Stratum mining protocol - ASIC ready - page 12.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: jborkl on February 19, 2013, 06:30:23 PM

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.

jborkl

sr. member

Activity: 246

Merit: 250

Team Heritage Motorsports

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.

eleuthria

legendary

Activity: 1750

Merit: 1007

Quote from: Luke-Jr on February 19, 2013, 04:52:44 PM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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?

BitcoinOxygen

sr. member

Activity: 336

Merit: 250

Quote from: Luke-Jr on February 14, 2013, 10:43:26 PM

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.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

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

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: slush on February 15, 2013, 02:09:25 PM

Quote from: zvs on February 15, 2013, 02:06:23 PM

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?

slush

legendary

Activity: 1386

Merit: 1097

Quote from: zvs on February 15, 2013, 02:06:23 PM

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

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Luke-Jr on February 15, 2013, 08:21:10 AM

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.

Quote

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 15, 2013, 07:45:15 AM

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.

slush

legendary

Activity: 1386

Merit: 1097

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 15, 2013, 07:08:42 AM

Quote from: -ck on February 14, 2013, 08:39:30 PM

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

legendary

Activity: 1386

Merit: 1097

Quote from: -ck on February 14, 2013, 08:39:30 PM

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 14, 2013, 10:03:12 AM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 14, 2013, 10:03:12 AM

Quote from: -ck on February 14, 2013, 09:29:39 AM

If just one pool op decides to implement this, I will support it in cgminer.

No problem. I just hope that the first daredevil will implement it properly, so response of mining.subscribe will have one extra argument 'session-id':

Quote

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

If this parameter is set and non-null, the miner will store sesssion id internally and then, after the crash of the connection, miner will call mining.resume('session-id') instead of mining.subscribe(...). Pool will respond with true/false. If true, miner can continue in the previous session (so re-upload pending shares, ...), if false, miner must call mining.subscribe and throw away pending shares.

Correct?

Nice.

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

fireduck

sr. member

Activity: 392

Merit: 251

Quote from: slush on February 14, 2013, 11:25:01 AM

Quote from: fireduck on February 14, 2013, 11:17:24 AM

So, I've just made SockThing use the same extranonce1 for all connections. I am also adding an extra random number to the coinbase and generate a new coinbase for each job.

Why is this better than generating custom extranonce1? Extranonce1 has been designed exactly for this. If you can achieve the same block template on all backends, then you can make session_id==extranonce1 and my proposal will work for you.

Yeah, your proposal is a clean way of doing it. Mine was just a hack to work within the existing protocol.

Topic: [ANN] Stratum mining protocol - ASIC ready - page 12. (Read 145773 times)