Question to all pool owners: fairness of payout per terabyte
It seems that most (all?) available pools currently skew payouts towards either big or small miners, and the difference in payout per terabyte of plots is huge: on pool.burst-team.us a miner with 100TB gets 50% more per terabyte than a miner with 10TB. This appeared on https://bitcointalk.org/index.php?topic=731923.msg19892877#msg19892877 and seems rather convincing.
What is the reason for this, and how did this come to be?
Current situation opens possibilities for some exploits. For example, if 10 friends with 100TB each plots agree to mine to the same account on pool.burst-team.us, then they would get 150% more per terabyte then those who mine with 10TB. This is roughly as if they were mining with 250TB each, 150TB for each is free. An opposite kind of situation is possible for pools which skew towards small miners.
While pool owners probably do not care about such issues (they get their fees anyway), it is not healthy for the community. I would really like to see a pool with fair payout per terabyte.
Should I start a new pool, where the payout is not skewed towards either big or small miners? And with no limit on the deadlines? I am still so much hoping that somebody else does this.
Well, a pool like that would really be great.
But, how do we make it work? How will you assign rewards per terabyte? The information for amount of space shown in some pools is not accurate always either.
@rattle99 Current pools use formulas for shares which are (rounghly) either deadline^(-1.2), or deadline^(-0.75). The first one gives more burst per terabyte to big miners, the second one to small miners.
Mathematically, the fair formula is deadline^(-1). On average it gives constant payout per terabyte. The parameter 1.2 or 0.75 is configurable, at least in the lux-uray pool source code. An ideal pool where I would mine would have this parameter set to 1, and no limit on deadlines.
@e1e1e1e1 the pools don't know how much you're mining with, so can't skew it in favor of one size miner or the other. I can't speak for the Uray/Lexicon pools, but the Ninja pools skew the payout in favor of the deadline, the better the deadline, the more you earn from it. So it's DL based, not capacity.
I will try to elaborate. I may not convince many of you, but if in doubt, show my post to somebody you trust who understands statistics and probability theory.
The way deadlines are computed, they are a random variables, uniformly distributed between 0 and a large number, related to the network difficulty. Our plots have many independent deadlines, and their minimum over a plot is (very close to) an exponentially distributed random variable with rate r proportional to the size of the plot.
I think that a fair way for computing shares in a round would be
share = 1000 /(c * max(1,deadline)),
where c is the constant related to the network difficulty, as it is currently used on uray-lex pools.
Thus way computed share is the maximum likelihood estimator of r, and the best estimate of miner's capacity (based on one round).
To distribute payouts over rounds where no shares are won, it would be wrong to sum up shares. The maximum likelihood estimator of capacity over n rounds is proportional to
1/(c_1 deadline_1 + ... + c_n deadline_n).
@haitch right, all pools are dl based, because there is no other way, and I am not looking for any other way. I am just trying to make payouts close to what people would be getting if they were solo mining, in the long run.
With the current algo in ninja pools, people with larger capacity get significantly more payouts per terabyte on average. And this is because of the formula used for computing shares. I think, you would agree that that formula matters strongly, right? I am just saying that it should be fixed.
@haitch by the way, can you show me the sources for the ninja pool?
@e1e1e1e1 The skew was added to the Ninja pools to make it fairer to the miner that actually won the round. With it unskewed a miner that won the round with a 5 second DL was paid only fractionally more than a miner who submitted a 6 second DL. It was agreed at the time that the actual block winner deserved a better share of the reward. As I understand it the skew tapers off very rapidly, so impacts those with the shortest deadlines, and barely impacts those with longer ones.
@haitch, I understand the intent and the logic, but I do not see a statistical justification.
I did some computations and simulations. I get good results if the payouts for every block won by a pool are distributed proportional to 1/(c_1 deadline_1 + ... + c_n deadline_n), where n is around 20. Such payouts very well correspond to the capacity, i.e. to what the miners would win independently (but over long time).