OK I'll ignore most of wizkids last post other than to point out that firstly, you've made your troll post about ckpool before,
and secondly, as I said last time, it's -ck you are trolling there not me.
Now regarding your ckpool trolling:
In stratum, difficulty isn't part of the work.
The only way to force a difficulty change to a miner is to make all it's current work stale, but after a difficulty change.
Yeah that's called ripping off the miner unless it's necessary.
Making work stale is only necessary on a block change, since of course any work they have for the previous block is stale and the new block change work (after the diff change) says that the old work is stale (clean_jobs)
But there's the (hidden) problem that doesn't really exist ... what work is valid with the new difficulty?
The stratum answer is: that all work sent, after the difficulty is sent, is valid on the new difficulty.
So the previous work is valid with the old difficulty until you no longer accept the previous work.
What does this solve:
If the miner is mining at 1000 Diff and gets a 1,000,000,000 diff share with the current work, it's still (correctly) only worth 1000 Diff.
If on the other hand, you allow a diff change to affect old work, then the miner could get a 1,000,000,000 diff share, then send the pool a request to change the difficulty up, and then get paid more for that share.
Yep that breaks the stratum rules.
.
.
.
However, most importantly, If your pool can't stop playing with the miner's difficulty then that's a problem with your code that deals with adjusting the miner's difficulty.
Get it right early on and then don't change it unless their hash rate changes drastically.
I don't believe I've posted on this particular issue with ckpool before. Maybe I did, but I don't recall doing so here, only on IRC. The issue I definitely mentioned previously on the forum is that ckpool doesn't create new work until GBT returns, which could be a problem with latency with a taxed bitcoind or whatever else would lag out GBT.
Anyway, your post appears mostly correct, except it doesn't tell the whole story.
While yes, if a miner is mining at difficulty 1,000 and finds a difficulty 1,000,000,000 share, they should be rewarded at difficulty 1,000.
With stratum, the pool sets the difficulty to 'X' and gives the miner some work. We'll call this work 'A'. The miner continues to work on that work at difficulty 'X' as long as it's valid. Now lets say the miner slows down (variance, lost a worker, whatever... it happens) and the pool adjusts the difficulty downward to say, 'X/2'. Soon after, potentially immediately, the pool sends a work update (NOT a restart, just an update). We'll call this work 'B'. The miner is still allowed to submit shares based on work 'A' for some time (as an example, Eligius allows this for 120 seconds).
Now the correct process is that work done and submitted based on work 'A' must meet or exceed difficulty 'X' and be rewarded to the miner at difficulty 'X' and work done and submitted based on work 'B' meet or exceed difficulty 'X/2' and be rewarded at difficulty 'X/2'. With me so far?
Here's where ckpool appears to screw this up. If the difficulty adjusts downward like in the above scenario, work from work 'A' is then rewarded at difficulty 'X/2' instead of 'X', even though the work meets or exceeds difficulty 'X' as defined for the work originally. (If the difficulty adjusts upward, then ckpool appropriately accepts work done.) So, for the short period miners are still working on work from work 'A' after the difficulty change and potentially before the pool even gives them work 'B', they're being shorted by the difference and this can last for as long as the miner continues to work on work 'A'.
Again, these are without work clears/full restarts/etc. Also, again, admittedly it's probably not very much of a problem, and I expect eventually someone will fix it, but it is there.
@kano did you catch my question at the end of my last post?
Edit:
Edit: ckpool can take 2 or 3 quick diff changes early on to get a good diff value, then doesn't change it for days/weeks - it's the most stable vardiff implementation around
You're probably right. Admittedly, eloipool's implementation works great as well when in arbitrary difficulty mode, but has some weak points when using only powers of two when it tries to pick a difficulty that is on the borderline. I get around this by just bumping everyone's up one notch.
Edit 2: Typos, quotes for clarity