OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[slush]

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

Inaba, why so aggressive? I never meet you on #stratum channel, so I'm bit surprised with your sudden interest in "proper design" of the protocol.

Did you read https://bitcointalk.org/index.php?topic=108533.msg1344456#msg1344456 ? AFAIK it fixes all previous problems with difficulty manipulation. I also didn't read any opinion to this by you, so I suppose you agree on this change. All existing miner software (cgminer, poclbm, proxy, I expect that bfgminer as well as it is derived from cgminer) is already compatible with this change, so feel free to implement it on your pool.

I only need to change documentation to cover this change. If we ever have days with 25 hours...

[1714887627]

1714887627

[1714887627]

1714887627

[PatMan]

So yeah, great miner guys, but there still seems to be some compatibility issues that need to be ironed out as far as the windoze side is concerned me thinks, but I don't blame you for not bothering too much about it, seeing as we all love windows so much.

Well... I actually have busted my balls for months on end trying to sort out the windows issues, so that is a slight understatement saying "not bothering much" 
 Enjoy anyway.

Of course, I realize that and appreciate all your hard work greatly - it was a very tongue in cheek comment, text can come across very blatant & uncaring sometimes - especially when I write it......

All good, and thanks again. Now that I'm mining properly again I'll make a wee donation - my first incoming will be yours my man.

First incoming donated as promised. It ain't much, as I've only got a small setup - but it's the thought that counts eh?

Thanks again for all your work on this, great stuff.

[cypherdoc]

con, have u ever considered using a PPA?  would help simpletons on ubuntu like me.

[Inaba]

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

Inaba, why so aggressive? I never meet you on #stratum channel, so I'm bit surprised with your sudden interest in "proper design" of the protocol.

Did you read https://bitcointalk.org/index.php?topic=108533.msg1344456#msg1344456 ? AFAIK it fixes all previous problems with difficulty manipulation. I also didn't read any opinion to this by you, so I suppose you agree on this change. All existing miner software (cgminer, poclbm, proxy, I expect that bfgminer as well as it is derived from cgminer) is already compatible with this change, so feel free to implement it on your pool.

I only need to change documentation to cover this change. If we ever have days with 25 hours...

With regards to being aggressive, I am irritated with the Stratum protocol in general.  It was developed in secret and foisted upon the mining world as the second coming of mining.  That's all well and good, but it was flawed and basically every single problem we've run into so far with it would have been fixed if it was developed in the open with input from the pool operators.  Instead, I'm stuck having to implement a broken protocol and make changes/fixes as the protocol is fixed in a manner that should have happened from the start... so yes, it's very irritating.  But what's done is done and I have not posted much in that thread because there's no sense in bitching about it; it is what it is.

Personally, I don't care what solution I use to solve the problems my pool is facing, so long as it works and doesn't cause problems down the road like GW has (but who can blame Tycho et al for GW since nobody really saw this scale of mining back then).  I digress... the current implementation other pools (IE - pools that are not EMC) have with Stratum is the hysterisis methods being employed are there to fix the (former?) problem with Stratum decoupling the difficulty from the work.  There is absolutely no compelling reason to make a large window of fluctuating difficulty, other than the fact that if you don't (on Stratum) shares are incorrectly discarded.  It's not like it requires a large amount of additional work on the miner end to have difficulty changing with every submission or anything.  Additionally, changing difficulty more often alleviates future problems with fluctuating hashrates. 

That said, it's something I wanted to bring up at some point:  I don't think you (Slush) or any of the other pool ops quite understand what's about to happen with regards to ASICs.  With these large difficulty windows, you are going to get flooded with shares as large scale miners come on and offline.  Even with Gen1 ASICs, the problem is going to be a bit pronounced on the larger pools as multi terahash miners come and go.  With Gen2, Gen3, and so on into the future, the problem will only magnify to unmanageable levels.  Waiting to change difficulty for longer than is necessary will only serve to flood your server with unnecessary work returns, increasing your load and potential points of failure.  Stop and consider what happens when 250 TH across 20 workers decides to hop on and off your pool... or even better yet, what if you get someone in control of 500 TH that decides to screw with your pool by hopping on and off your pool in a manner that will keep the difficulty lower than it should be?  This is going to be a problem, either through malicious acts or through random chance - it's why I do not allow user selected difficulty on EMC and why I have difficulty changing fairly rapidly.  I don't want to get DoS'd either through intention or not simply because I have 500 TH submitting difficulty 32 shares for 5 minutes before they get bumped up, rinse and repeat.  There is no drawback to rapid difficulty change in the ASIC era, and artificially limiting that to accommodate a problem with the protocol instead of fixing the protocol is backwards thinking.

I'll review the changes you mentioned... from a cursory glance, it doesn't seem to address what happens when a worker submits a share from a previous work block that had a lower difficulty or does it?  Your post is a little unclear on that, so if you could clarify that, it would help and I will work to get that incorporated in EMC. 

Assuming that addresses the fundamental issue of a miner submitting a lower difficulty share that is still valid after the difficulty has increased, does that address the problems CGMiner is having with EMC and it's rapid difficulty changes, Con?   If not, can you elaborate on exactly what the problem is with CGMiner and EMC over Stratum?

[slush]

It was developed in secret and foisted upon the mining world as the second coming of mining.

Fuck off. I'm impatiently waiting to your open initiative for ASIC device-level protocol. I don't believe that somebody with your attitude is preparing proprietary protocol which must be adopted by the community to use your miners.

That's all well and good, but it was flawed and basically every single problem we've run into so far with it would have been fixed if it was developed in the open with input from the pool operators.

I'm also impatiently waiting to your open proposal for mining protocol which will be superior to Stratum. I implemented the protocol which fits my needs. I don't keep gun to any poolop's head to support Stratum as well. If you don't like Stratum, stay away from it.

I cannot resist your arrogant style. But fine, I'm calming down and I'll try to be constructive now...

Personally, I don't care what solution I use to solve the problems my pool is facing

Pretty vague sentence. Can you be more specific? Why you didn't report your problems?

There is absolutely no compelling reason to make a large window of fluctuating difficulty, other than the fact that if you don't (on Stratum) shares are incorrectly discarded.

I don't believe you wrote such long post before you even read my post addressing this issue. Btw protocol don't define *any* window, it's up to server side implementation.

I don't think you (Slush) or any of the other pool ops quite understand what's about to happen with regards to ASICs.

I think that I understand it pretty good. Any evidence for your claim? Can you elaborate more on Stratum bottlenecks regards to ASICs and what's your solution then?

 With these large difficulty windows

Large difficulty windows are in your head, not in the protocol. Protocol don't care about any windows, pool can enforce difficulty every second. It is completely up to pool implementation and there are NO limits defined in the protocol in this area.

Waiting to change difficulty for longer than is necessary will only serve to flood your server with unnecessary work returns

How is this liimited by the protocol? For example, my vardiff code is rising the difficulty pretty aggressive and in the near future, pool even won't use diff1 on the beginning of the connection. Slower miners will wait a moment until the difficulty settle to lower values. Mining on diff1 is going to die in very near future anyway, I believe that default connection difficulty will skyrocket in few months.

Stop and consider what happens when 250 TH across 20 workers decides to hop on and off your pool...

Hm, still don't understand how this is related to the protocol and not to the pool implementation. Can you elaborate a bit more? I'm affraid you're mixing together possible problems of miner implementation, server implementation and the protocol...

what if you get someone in control of 500 TH that decides to screw with your pool by hopping on and off your pool

There're much simpler solutions how to DoS the pool, than hoping with real 500 TH/s. But fine, every solution which will save pool from overloading is welcome. What's yours proposal?

it's why I do not allow user selected difficulty on EMC and why I have difficulty changing fairly rapidly.

Exactly my solution. Again, clearly possible with Stratum.

from a cursory glance, it doesn't seem to address what happens when a worker submits a share from a previous work block that had a lower difficulty or does it?

Correct, it doesn't address submitting old shares. AFAIK there's no easy solution how to check if the share has good difficulty until you validate it on the server. What's your proposal here? Even banning the IP won't solve the problem, it only saves a bit of pool CPU time, but validating the share is quite cheap anyway...

Inaba, I ask you to calm down your tone. If you have any problems with the solution, you can report them and offer the solution in inteligent way.

[DrHaribo]

Trying to implement Stratum on my pool, but cgminer crashes when I connect to the server.

This is what happens, from the server perspective:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","1"],"",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Then Windows says "cgminer.exe has stopped working"

[-ck]

Trying to implement Stratum on my pool, but cgminer crashes when I connect to the server.

This is what happens, from the server perspective:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","1"],"",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Then Windows says "cgminer.exe has stopped working"

See Eleuthria's cheat sheet:
https://www.btcguild.com/new_protocol.php

You're sending a zero sized  string for extranonce1

[DrHaribo]

You're sending a zero sized  string for extranonce1

I thought that was allowed. Anyway it doesn't help changing that:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Still crash.

[Inaba]

Fuck Off, really?  That's where we are at now?

I'm impatiently waiting to your open initiative for ASIC device-level protocol. I don't believe that somebody with your attitude is preparing proprietary protocol which must be adopted by the community to use your miners.

You're absolutely right I'm not preparing a proprietary protocol!  I am 100% against doing so, which is what you did and then "opened it up" to the community.  That's what irritates me, but it's a minor irritation which is why I've not made a big long posts about it.  I'm sure you had your reasons and as I said, what's done is done.

I'm also impatiently waiting to your open proposal for mining protocol which will be superior to Stratum. I implemented the protocol which fits my needs. I don't keep gun to any poolop's head to support Stratum as well. If you don't like Stratum, stay away from it.

Why are you waiting for my proposal if you already have one that fits your needs?  That doesn't even make sense!

Pretty vague sentence. Can you be more specific? Why you didn't report your problems?

I did (https://bitcointalk.org/index.php?topic=108533.msg1344256#msg1344256).  You did not respond, so what do you want me to do, pitch a fit in the thread?

don't believe you wrote such long post before you even read my post addressing this issue. Btw protocol don't define *any* window, it's up to server side implementation.

I don't know what you mean by this so it's hard to respond.  Ok, the protocol doesn't define a window, fair enough.  However, because the protocol fails to tie the difficulty to the work, some pools are putting in a window to fix the broken protocol and solve an issue that should not even be an issue.  If the difficulty were tied to the work, as it should be, it would be completely irrelevant when the share is sent back (so long as it's not expired) when viewed in relation to the current work being sent out at a higher difficulty.  

From your responses in that thread, you seem to think it is ok to discard valid work simply because the difficulty rises in the middle of a nonce.  That is basically robbing the miners of valid work and it's not something I am willing to do to my miners.  Yes, absolutely, I agree that it's a very small amount of shares, but the cumulative discards of perfectly valid shares is not insubstantial.  And this is all because difficulty is not tied to work.  Tie difficulty to work and this problem goes away.

I think that I understand it pretty good. Any evidence for your claim? Can you elaborate more on Stratum bottlenecks regards to ASICs and what's your solution then?

I did not say there were any bottlenecks in Stratum, but your response further lends credence to the fact that I don't think you understand the scale of what is about to be unleashed upon the mining world.  You are still thinking in the old mining terms were 100 TH is virtually inconceivable (Given that the whole network is a fraction of that right now).  Within less than a year, 100 TH will be well within the reach of modest professional miners and I will not be surprised to see the largest miners wielding a significant fraction of a PH.  But this isn't really a Stratum issue, beyond the fact that the discarded shares will scale in a linear fashion with the hashrate and miners will be losing a non-trivial amount of shares for no reason when mining with Stratum on current implementations.

Large difficulty windows are in your head, not in the protocol. Protocol don't care about any windows, pool can enforce difficulty every second. It is completely up to pool implementation and there are NO limits defined in the protocol in this area.

See above.  The difficulty windows are in response to fact that Stratum does not properly tie difficulty to work.

How is this liimited by the protocol? For example, my vardiff code is rising the difficulty pretty aggressive and in the near future, pool even won't use diff1 on the beginning of the connection. Slower miners will wait a moment until the difficulty settle to lower values. Mining on diff1 is going to die in very near future anyway, I believe that default connection difficulty will skyrocket in few months.

Again, see above. To overcome the flaw in the protocol, apparently the solution BTCGuild and OzCoin have come up with is to make a large hysteresis window to prevent frequent difficulty changes and to minimize the impact of lost shares.  That's a kludge to fix a problem that shouldn't exist, which is directly caused by the protocol specification.

Exactly my solution. Again, clearly possible with Stratum.

Ok, fair enough.  Maybe Con can chime in then and tell me what the difference is between EMC and Slush's pool as viewed by CGMiner?  All this is ultimately due to CGMiner apparently having trouble with EMC because the difficulty changes too rapidly - but if that's the case, wouldn't the same problem be evident on Slush's pool?  If not, why not?  I'll be glad to fix it if there's a problem somewhere.

Correct, it doesn't address submitting old shares. AFAIK there's no easy solution how to check if the share has good difficulty until you validate it on the server. What's your proposal here? Even banning the IP won't solve the problem, it only saves a bit of pool CPU time, but validating the share is quite cheap anyway...

What?  Of course there is!  Tie difficulty to the work sent out.  When the work is returned, compare it to the difficulty sent out, if it's under the target you're good to go, if not, reject it.  Simple, easy, obvious and straight forward.  I know you are aware of this, since it's been brought to your attention several times by several different people.  So I'm confused on what you are trying to say here?

Inaba, I ask you to calm down your tone. If you have any problems with the solution, you can report them and offer the solution in inteligent way.

Umm, my tone?  What are you talking about?  I made a comment in this thread, about CGMiner, explaining why Stratum is not correct and you come back at me with Fuck Off because I answered your question.  The problem with Stratum has already been beat to death in the other thread, so why should I go there and beat that dead horse again?  You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times.  

[-ck]

You're sending a zero sized  string for extranonce1

I thought that was allowed. Anyway it doesn't help changing that:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Still crash.

Oh sorry. Send your first set of parameters for mining.notify before sending the ack for mining.authorize.

Something like

Code:

Server: {"params": ["bf", "4d16b6f85af6e2198f44ae2a6de67f78487ae5611b77c6c0440b921e00000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff20020862062f503253482f04b8864e5008",
"072f736c7573682f000000000100f2052a010000001976a914d23fcdf86f7e756a64a7a9688ef9903327048ed988ac00000000",
["c5bd77249e27c2d3a3602dd35c3364a7983900b64a34644d03b930bfdb19c0e5","049b4e78e2d0b24f7c6a2856aa7b41811ed961ee52ae75527df9e80043fd2f12"],
"00000002", "1c2ac4af", "504e86b9", false], "id": null, "method": "mining.notify"}\n
Server: {"error": null, "id": 1, "result": true}\n

[DrHaribo]

You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times.  

Apparently he changed his mind. Look in the Stratum thread. I am implementing server-side Stratum now and I'm going to have difficulty tied to work. I'll send set_difficulty before the work, unless it is the same diff as the previous work, in which case I'll skip sending set_difficulty.

Oh sorry. Send your first set of parameters for mining.notify before sending the ack for mining.authorize.

That's not helping either. I'm wondering if it has to do with my formatting being different (from other Stratum pool implementations).

Code:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
send: {"method":"mining.set_difficulty","params":[1],"id":1}
send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}
recv: {"id": 2, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":2}

The strange thing is that now it tries to authorize twice, with a 10 second pause in between, then crash.

[slush]

Fuck Off, really?  That's where we are at now?

I've been just upset by your tone. Maybe you didn't noticed the aggression in your posts.

You're absolutely right I'm not preparing a proprietary protocol!

Umm, it's a bit offtopic here, but is protocol for BFL ASICs already documented somewhere?

Why are you waiting for my proposal if you already have one that fits your needs?  That doesn't even make sense!

Because you're bashing the Stratum, without giving any solution!

I did (https://bitcointalk.org/index.php?topic=108533.msg1344256#msg1344256).  You did not respond, so what do you want me to do, pitch a fit in the thread?

Well, it was addressed to ckolivas and cgminer implementation...

don't believe you wrote such long post before you even read my post addressing this issue. Btw protocol don't define *any* window, it's up to server side implementation.

I don't know what you mean by this so it's hard to respond.

Fair enough. My english is strange, I know, but you can always ask for further explanation...

If the difficulty were tied to the work, as it should be

It already is, you just didn't notice it. I finally updated the documentation, which is backward compatible, but practically solves your issue: https://bitcointalk.org/index.php?topic=108533.msg1356993#msg1356993

From your responses in that thread, you seem to think it is ok to discard valid work simply because the difficulty rises in the middle of a nonce.

I don't think it's ok to discard valid work, I just didn't know about proper solution. But I think that I already found it, all people which I asked were fine with it, so I think we're now talking about non issue...

I did not say there were any bottlenecks in Stratum .... But this isn't really a Stratum issue

Fine to know it.

Again, see above. To overcome the flaw in the protocol, apparently the solution BTCGuild and OzCoin have come up with is to make a large hysteresis window to prevent frequent difficulty changes and to minimize the impact of lost shares.

No, at least not for BTCGuild. AFAIK "difficulty windows" were implemented by Eleuthria because he creates jobs pool-wide (exactly as I'm doing on my pool now, although my development code can generate ondemand jobs as well), so creating jobs on-demand for the miner is difficult. That's not related to difficulty manipulation at all.

Ok, fair enough.  Maybe Con can chime in then and tell me what the difference is between EMC and Slush's pool as viewed by CGMiner?  All this is ultimately due to CGMiner apparently having trouble with EMC because the difficulty changes too rapidly - but if that's the case, wouldn't the same problem be evident on Slush's pool?  If not, why not?  I'll be glad to fix it if there's a problem somewhere.

To be honest, vardiff isn't on my production servers yet. Still there's no obvious reason why miner should have problems with often changes of the difficult. Did you tried poclbm instead of cgminer to check if this behaviour is miner-dependent?

What?  Of course there is!  Tie difficulty to the work sent out.  When the work is returned, compare it to the difficulty sent out, if it's under the target you're good to go, if not, reject it.  Simple, easy, obvious and straight forward.

Umm, well, for comparing the difficulty, you firstly have to compute doublesha256 of submitted share, what I call "share validation". Is there any shortcut how to check difficulty of submitted share? Not necessary on Stratum, but maybe in GBT? I'm not aware of any easy solution.

you come back at me with Fuck Off because I answered your question.

No, that fuck off was related to bolded part of your sentence. About FUD that I created Stratum behind closed doors to dominate Bitcoin mining. I'm free person and I can develop any protocol what I want. And you're free person and you can ignore results of my work. I don't have any super power to enforce my solution to be accepted by the community. Did you noticed that Satoshi also created Bitcoin behind closed doors and then he released it as opensource?

[slush]

You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times. 

Apparently he changed his mind. Look in the Stratum thread. I am implementing server-side Stratum now and I'm going to have difficulty tied to work. I'll send set_difficulty before the work, unless it is the same diff as the previous work, in which case I'll skip sending set_difficulty.

Yes, this is one of perfectly valid solutions.

Solution which I'm implementing for my pool is that code managing difficulties is completely independent from broadcasting the jobs, and it can send set_difficulty at any time. Only when the difficulty step will be big enough (typically on the beginning of the connection with high hashrate), difficulty-managing code will generate per-miner job and sends it with "clean_jobs=True", enforcing miner to change difficulty immediately and prevent pool overflooding. With this solution, there's no need for any "difficulty windows".

[MrTeal]

I did not say there were any bottlenecks in Stratum, but your response further lends credence to the fact that I don't think you understand the scale of what is about to be unleashed upon the mining world.  You are still thinking in the old mining terms were 100 TH is virtually inconceivable (Given that the whole network is a fraction of that right now).  Within less than a year, 100 TH will be well within the reach of modest professional miners and I will not be surprised to see the largest miners wielding a significant fraction of a PH.  But this isn't really a Stratum issue, beyond the fact that the discarded shares will scale in a linear fashion with the hashrate and miners will be losing a non-trivial amount of shares for no reason when mining with Stratum on current implementations.

That's interesting. At your current prices, 100TH/s would be a $2,000,000 investment and half a PH/s would be $10M. Considering that $2M invested now would make you far and away the largest miner on the network, it seems you either expect investment in mining hardware to go way up or the price per GH/s to plummet. You were asked on the BFL forums about your plans to drop prices shortly and said you had no plans for a price cut, but if you're expecting 100TH/s to be a modest pro miner in the future you must surely be expecting some large changes from the current ASIC status quo.

[Luke-Jr]

I for one would prefer to see all this back-and-forth spent improving stratum or some new protocol.
How goes preparing the first BIP draft, slush?

[-ck]

Ok, fair enough.  Maybe Con can chime in then and tell me what the difference is between EMC and Slush's pool as viewed by CGMiner?  All this is ultimately due to CGMiner apparently having trouble with EMC because the difficulty changes too rapidly - but if that's the case, wouldn't the same problem be evident on Slush's pool?  If not, why not?  I'll be glad to fix it if there's a problem somewhere.

Actually, I wasn't comparing you to slush's pool because ironically... slush's pool doesn't do vardiff yet. ozcoin and btcguild are the other pools I can compare to. Make what you want of that fact.

So the issue really comes down to the round trip of network time between pool sending out diff and miner receiving it, and the miner sending out a share. Most of us have round trips of ~500ms across real internets, though some of you are seeing ping times of <50ms but this does not translate to a processing, submission and return time of 50ms. Luckily c is fast so cgminer intrinsically doesn't add *that* much processing time, but it does add time.

There are 4 distinctly different scenarios with changing diff separate from work.
A. Diff rises before cgminer submits lower diff share and cgminer is aware of it
B. Diff falls before cgminer submits now adequate diff share and cgminer is aware of it
C. Diff rises in the round-trip window period as cgminer has already submitted a share below difficulty and cgminer is not aware of the new diff
D. Diff falls in the round-trip window period as cgminer has discarded a share that would now be adequate as cgminer is not aware of the new diff

cgminer can only do something about scenario A and B. C and D are entirely out of its control. The way I decided to manage these situations is based on maximising the possible paid share submission.

Scenario A:
cgminer can decide to retarget for the higher difficulty and not submit the share. It currently does NOT do this, instead keeping the difficulty target at the original lower value, in case pools have a grace period at the lower difficulty. It risks rejects but no shares are lost in this way. This is what causes more rejects on EMC when the difficulty is retargeted often. However no paid work is lost here.

Scenario B:
cgminer can decide to retarget for the lower difficulty and submit the share. cgminer does this since clearly this share is now work it will get paid for. No paid work is lost here, and no rejects are induced.

Scenario C:
cgminer can't do anything about it, but this registers as a reject. Any increase of diff by a pool can elicit this, and the more often the difficulty is raised, the more rejects will be seen. Once again, no paid work is lost here.

Scenario D:
cgminer can't do anything about it, and this work is lost. Any decrease of diff by a pool can elicit this, and the more often the difficulty is lowered, the more shares are lost. No rejects are induced.


So there is a round-trip window period for scenario D where shares are potentially lost. If you have a 500ms round trip window, then you lose .5 seconds worth of possible lower difficulty shares with each drop. The more decreases, the more lost.


The only changes I can make to cgminer's default behaviour to help here is scenario A, and retarget to the higher difficulty. Note that the emphasis is always on submitting shares that are possibly paid for over minimising rejects. B is fine. Nothing can be done about the rejects in C, but no paid shares are lost. D is the real issue that nothing can be done about, and unless difficulty is tied to the work, it ends up being dependent on how often the pool ends up changing difficulty that determines how much work is lost, and secondarily the visible rejects.

I agree that retargeting with vardiff is important or floods of low diff shares will be a real issue. However retargeting for small changes in difficulty based on share submission, which is subject to large amounts of variance, will see lots of changes of difficulty and the inherent rise in rejects and lost shares.

EDIT: Note that my scenario A management is in line with slush's change to the protocol stipulating changes to diff apply to next work sent by server, not existing work.

[slush]

How goes preparing the first BIP draft, slush?

Not very well. I just found https://www.btcguild.com/new_protocol.php written by Eleuthria and I think this can be quite nice start for the BIP. In contrast to Eleuthria, I'm pretty bad writer and my expression capabilities are a bit limited.

[-ck]

You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times.  

Apparently he changed his mind. Look in the Stratum thread. I am implementing server-side Stratum now and I'm going to have difficulty tied to work. I'll send set_difficulty before the work, unless it is the same diff as the previous work, in which case I'll skip sending set_difficulty.

Oh sorry. Send your first set of parameters for mining.notify before sending the ack for mining.authorize.

That's not helping either. I'm wondering if it has to do with my formatting being different (from other Stratum pool implementations).

Code:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
send: {"method":"mining.set_difficulty","params":[1],"id":1}
send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}
recv: {"id": 2, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":2}

The strange thing is that now it tries to authorize twice, with a 10 second pause in between, then crash.

I'm lost as to what's wrong then. It seems you're running windows which makes debugging a pain as well. Are you running the latest 2.9.5? 2.9.4 was crashing on extracting gbt information from your pool occasionally (obviously unrelated to stratum). There are debug builds here along with instructions for debugging on windows: http://ck.kolivas.org/apps/cgminer/debug/ .

[awatson824]

Ckolivas, is it my computer or graphics card that is giving me 46 stales in 8 hours?
Not being mean just asking cause I don't get it. :/

[slush]

send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5 135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000 000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21 a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}

! :-)