...
As for bankruptcy payout - the main problem I'd see there from DGM vs PPS (or some of the different PPS) is that no one can probably work out the owed amount on DGM since there is a future component to that, that depends on the future also.
On PPS it's pretty simple.
You can calculate the expected future payment for a given score. (Actually, you can parametrize it so that the expected payout
is the score). The operator should pay that out so that miners won't suffer (I'm assuming a deterministic payout is considered better than a variable payout of the same expectation). The total score of all miners is bounded, and the operator should have this as an additional reserve - he should declare bankruptcy before he becomes unable to offer a cashout.
Just thought I'd mention that you seem to be discussing exactly what I was referring to here ...
Expected payout is one thing, variance is another, maturity time is another. Expected payout is the most important and easiest to calculate, and it's safe to refer to it as the amount owed.
It should be possible to create a dataset by running for various parameters, and then interpolating for all other values. Then each pool can show values or graphs for their chosen parameters, and allow the user to set his hashrate with a slider to his how specific results. I have reason to believe that the variance is affine in the miner's hashrate (at least approximately), so that simplifies things. If the interpolation can be done easily enough, maybe the pool can also give sliders for seeing the results for various DGM parameters.
The important parameters being f, c, o, and miner hashrate as a proportion of pool hashrate? Let me know if I missed anything.
A measure of the miner's intermittency would also be good to have.
By the way, in AoBPMRS I mentioned that it's not strictly necessary that all miners in a pool will have the same parameters. So it could be possible for miners to choose their own parameters based on their desired performance metrics.
I didn't see that mentioned explicitly - is it implied?
It's fairly explicit in section 7.4, "Heterogeneous pools".
so miner average hashrate and pool average hashrate over the round
to be able to make that assumption - cheers
Variability in pool hashrate is in a sense equivalent to variability in miner hashrate, which I think should be included. One issue is that the specific form of variability will be different, but perhaps it is possible to encode it approximately with a single value.