Variable difficulty -has- to adjust upon new work without being opened up to exploitation, regardless of protocol used. It's very simple for a fast miner to withhold higher difficulty shares when it knows that it's going to force a difficulty increase, then submit them for higher credit once the adjustment lands.
Which - if I'm reading the spec right - is quite hard to do with the current protocol. Even if you change the difficulty at the exact same moment as sending out a new work unit, the difficulty change applies to all the previous work units and miners are allowed to continue working on those at the new difficulty unless you invalidate all of them at the same time. Except that if you do that, you're making the miner throw away work they've done without submitting it. There's a mismatch between how the protocol wants you to handle difficulty changes and the way you actually need to handle them to prevent cheating by miners.
btcguild is the only stratum pool with variable diff, and it sends out a clean work with every difficulty change meaning all work gets thrown out with each diff change. Even blocks and valid shares at the new diff get thrown out I might add.
Quite logically, the implementation should be that difficulty should be part of the work, however, previous work on the same block should also be allowed since it is to the miners disadvantage for the pool to throw away valid work ... obviously
This does, however, lead to the issue that pools may be silly enough to send a 1TH/s miner 1 difficulty work.
Yeah it seems that it is impossible for the pool software programmers to handle this properly ... the solution seems to be that it's the miners problem, not the pools problem, so the miner should lose work because of it ... yet the protocol clearly states that it's the pool that has absolute control of this.
I guess setting a time limit on how much old work is valid (yes there was a reason I made that comment at the end of the post:
https://bt.irlbtc.com/view/108533.msg1287015#msg1287015 ) and the pools will just have to put up with this time limit since they are unable to program a suitable solution without throwing away valid miners work.
Hmm - looking at the protocol in the light of this discussion, it really currently is a protocol that gives more power to the pool and takes it away from the miner.
The protocol, by definition, allows the pool to reject shares as it chooses and gives a way to do that, that the protocol defines as valid.
Giving the pool WAY less work to do, and passing that work reduction to the miner to do, yet the miner also loses rights about the pool accepting it's valid work ... hmm ... giving away rights and being made to do more work ... where have I heard that before
The point of this protocol was a long term solution, but with getwork using roll-n-time and high difficulty shares, it won't be necessary quite yet.
A 1.5TH/s device can do ~233 nonce ranges a second, so with the roll-n-time limit set to 7000 as it is in cgminer at the moment, that's 30s worth of work ... so there is still some (small? amount) of time left before people are forced to give away rights and do more work ... and in the mean time there may be a better solution ...
