Thanks for the response, you are absolutely right. I do pull the statistics via the JSON API every 10 minutes and analyse & plot it automatically every 6 hours. (I do not want to pull more frequently for practical reasons.)
At this point in time, based on stats from the last 2 months, what I see confirmed is the "magical fix" manual recalculation via PPS which is easy to spot and slush has been honest about it when I contacted him (he is very open and honest, and I do understand him not wanting to actively post here recently).
Can you explain this? PM me if you don't want to post publicly.
I do not think that based on my current amount of data I could back my assertion beyond a doubt, this is why I was very explicitly calling it a guess. I could collect data and perform "black box analysis" for any amount of time and still not reach 100% as it is theoretically impossible to reach 100% via passive black box analysis but the confidence level is growing with the amount of data collected.
Great! Have you been able to calculate 'c' yet? Having this will allow you to back calculate shares which will make figuring out the renormalisation easier.
Checking the code (aka white box analysis) could be much less effort taking and allow for a statement beyond doubt. And honestly, I have never even seen a precise description of what exactly is done on a renormalisation, only the fact is mentioned that a renormalisation is periodically performed. In contrast to this, Meni Rosenfeld is very explicit in how rescaling should work when using DGM (https://bitcointalk.org/index.php?topic=39497.0
I thought there was one somewhere. Maybe not. I'll try to find it, if it exists.
Regarding changes to C: what I mean is that on rescaling/renormalization, when the score is changed, but C is not, then you very aggressively change the weight of all the work one has performed before renormalisation versus the weight of the new per share increment. However, if the score is divided by X, and C multiplied by log(X), then the value of previous scores relative to the value of the increment score for the new share is kept the same (maintaining the exponential semantics used by slush), and you will end up with the same exponential curve, just rescaled (zoomed out).
Since 'c' can't be changed without completely changing the 'hoppability' of the pool, you are in effect saying that given this restriction proper renormalisation or rescaling can't occur? Hmmm. Have to think about that.
You've obviously done a lot of work - you should post your results somewhere on the forum, as a work in progress. I'm keen to see what you have.