--diff acts as a starting difficulty with vardiff enabled

[ericecook]

Although I think we should probably not actually rigidly follow the difficulty specified, or a malicious user could flood the server with low difficulty shares, we should probably never adjust to a difficulty lower than what is set.

Clarification by icook: --diff argument in password field acts as a starting difficulty on vardiff, but a fixed difficulty on fixed diff. This was not intended behaviour.

[icook]

I honestly think this is valuable behavior, so the bigger question is should we keep the current behaviour and change docs, or should we add different args for more specific, less "magic" behaviour. I see three main difficulty adjustment needs:

1. Starting difficulty on Vardiff port is too low. Probably will be a bigger problem once we clamp down hard on share submission rate limiting. Probably quite common for big farms, etc. For this, setting a different starting diff for vardiff seems useful.
2. For whatever reason (bandwidth, stale rate, etc) I don't want my difficulty to be below X. Higher is okay.
3. Just let me pick a damn fixed difficulty.

So, some possible configurability semantics:

1. --diff set with specific difficulty will clamp and not change.
2. --diff can be set to a range, like 512 - 2048 and vardiff will switch within ranges to some default sps rate.
3. --sps can be set to define target shares per second target.
4. --start-diff simply changes starting difficulty when connected.

To avoid potential DOS vecotrs we need to:

1. Provide minimums and maximums on --diff, --start-diff, and --sps
2. Adjust their difficulty regardless of settings if sps exceeds some specified number.

Thoughts on this? I think this is closely tied to my end goal of not having "vardiff" ports or "highdiff" ports, but rather port defaults and each port can be configured how you'd like.

[ericecook]

I was thinking along similar lines, but hadn't thought about allowing --sps, very cool idea.

Ideally I think we need to be shooting towards a single port per currency (with sensible + configurable defaults), or we're gonna end up with a pretty crazy amount of ports to pick from, with little actual difference between them.

As a passing thought...

What do you think of allowing users with who donate to the pool to set a higher min/max on some of these things? That way we can provide really slick graphs for people who want 'em, and it covers the increased resource usage. Should be easy to implement by periodically throwing a few keys in Redis.

[icook]

So this is really several work chunks:

1. Adding start diff flag. This is a trivial if statement on connect state
2. Changing --diff to disable vardiff. There's no connection based mechanic for this, but adding one is pretty simple. Most of the checks check the server vardiff enabled. Easiest would be to copy the server's vardiff enabled flag when creating the client object, then check based on that (a copy essentially). Changing the flag is then per connection, and can be set to false when --diff is specified.
3. Changing vardiff to a different range. This is a bit more tricky since I'm not sure how gradations would be generated. I suppose any pre-existing that fell within the range requested, plus the upper and lower bounds? That's not too hard, but testing it is a bit annoying.
4. Changing shares per second. This would be done similar to 2 I suppose, by copying the default to a connection local setting and making it changeable.

[ericecook]

That sounds pretty straightforward.

Long term I'd like to be able to adjust difficulty on-the-fly. For example, if the server is under high load it'd be nice to just bump everyone's difficulty up a bit. Or adjust difficulty/sps for users who set theirs to be super spammy.

Perhaps that is an issue for later. But it might be able to be accomplished by instead of switching the vardiff flag off, to instead changing the vardiff range to a single item? The downside would be running the vardiff calculation unnecessarily quite a lot.

[icook]

Eh, I'd rather do the flag. Flag checking already occurs, and I we'd be forced to do 90% of the work for 4 just to accomplish 2.

As for changing peoples diff all at once, etc, I think with 0.7 having the connection states in Redis will make this pretty easy.

[ghost]

I have been Lyra2RE CPU mining (https://github.com/tpruvot/cpuminer-multi) on the variable difficulty port at SimpleMulti.com (stratum+tcp://ca.simplemulti.com:3374). My difficulty gets set to 0.08 after a few seconds and my CPU mines away... However, about every 20 minutes the miner "takes a break" while the stratum sends more work: http://imgur.com/1cmxrEp This waiting process takes about 2 to 3 minutes. I would really like to see a steady stream of work flowing in. I am able to replicate this on multiple computers.

I am wondering if I am being flagged for submitting shares too quickly at too low a difficulty and the stratum closes my connection for a few minutes. Is there a solution for this? In the interim, I am pointing my CPU miners at the Lyra2RE fixed-difficulty port (stratum+tcp://ca.simplemulti.com:3373).This definitely has slowed down my submission rate, but the CPUs are never idle, and the shares are worth significantly more.

Is there any way to have the pool auto-adjust the difficulty up from 0.08 to something higher when mining on the variable difficulty port so that the miner is not ever disconnected and forced to reset? It really appears that if your submission rate per minute, with low difficulty, is to too high, you are throttled.

Mining Lyra2RE at yaamp.com does not have this same "reset" every few minutes. I am not sure what the difference is.

[ericecook]

@jakerich No, there is no way to manually adjust below 0.64. We've intentionally set the minimum manual difficulty at a moderate level to prevent abuse. SimpleMulti does no throttling, If you were submitting shares too quickly your difficulty would be increased. It is possible there is a bug causing the disconnects (possibly related to https://github.com/simplecrypto/powerpool/issues/113 ?) but this could also be a network connectivity issue.