Quote from: btcmonkey on July 29, 2011, 01:41:56 PM

I have not had a lot of success getting your proof to render for me. Can you describe how you came up with the decay factor, r? Isn't it really a growth factor for any reasonable c?

It's growth in the score of new shares, but a decay in the value of old shares. It's the unique value that makes the sums come out right. In fact you could choose r first and then find c, the average score fee, in terms of r.

Quote from: btcmonkey on July 29, 2011, 01:41:56 PM

Is it true that for a very low number of shares ( < 1000 ) at the current difficulty, the total fee gets really large ( > 50% ) when c = 0.001? My implementation seems to show this. Does this mean that a really lucky block find would mean bad news for pool members, or is my implementation flawed?

Yes, the fee is large for short rounds. This is because there aren't many participants to receive a reward, otherwise early miners would get a disproportionate reward.

Quote from: btcmonkey on July 29, 2011, 01:41:56 PM

Expanding on this, what impact would having the score start at some high arbitrary number (e.g. r^10000) instead of 1 have? It seems it could enable setting a max value for what fee would be taken, but I'm not sure how doing this would effect the cheat-proofness of the system and expected fee calculations.

If you do this and keep the score fee as stated, it will be like decreasing the score fee, which means that this is no longer hopping-proof.

Quote from: btcmonkey on July 29, 2011, 01:41:56 PM

For difficulty 2 and difficulty 3 shares is p simply 2/difficulty and 3/difficulty respectively?

Yes.

All in all the method was designed for everything to be 100% accurate in expectation, though this means relatively high variance and some counterintuitive situations.