OrganOfCorti,
I have read many of your writings and comments here and I am convinced you do know very well what you are talking about. However, with all respect I am not sure you are 100% right in this case.Yes, what you write is how it should work, but I wonder if you have seen and analysed the actual code performing the renormalization. What we know from experience is, that a round, that ended very closely after a renormalisation, yields rewards being off by magnitudes, which affects some miners in a positive, others in a negative way. It seems, the closer to a renormalisation the round ends, the larger the deviation from the expected avg reward.
No, no-one I know has audited slush's code. So any claims that the renormalisation is broken need to be proven - anecdotal evidence is insufficient. You'll need to prove your assertion beyond a doubt, not just show examples of when you think it misfires. ou could be correct - why not actually do the groundwork and prove it?
My guess (which is only a guess based on observations) is that constant C in the formula is not changed after the renormalisation to match the scale-down factor of existing scores.
If it was correctly changed, then a share submitted right after a renormalization would have the same impact/importance, than the share submitted right before the renormalization. This does not seem to be the case.
'c' should never be changed. If it did, the score method wouldn't work.
In really extreme cases, where the deviation is significant (e.g. only a few satoshis for continuous miners even at around 1Gh/s), Slush recalculates the blocks manually with PPS. You can see that after a "magical fix" that we see in some cases your score is equal to the number of shares you submitted. (I have been collecting and storing block stats for two months and am not just making this up.)
Please let me know if you think I made a logical mistake in my conclusions, I am always open to learn. And it also belongs to learning to periodically revisit and challenge previous theories and statements. So no offence is intended whatsoever.
Cheers,
T
You think something's wrong - fair enough. But now you need to prove it. You'll need lots of data, and you'll have to scrape slush's site every few minutes. But it's doable.
Good luck!
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).
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.
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://bitcointalksearch.org/topic/double-geometric-method-hopping-proof-low-variance-reward-system-39497).
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).
Cheers,
T