tl; dr: Like Mine in multiple pools to reduce variance, but for PPS. I describe a system that allows enjoying the benefits of PPS without the downsides. In particular it can dissolve the problem of concentrating mining within a few pools. I believe this is what pooled mining will look like in the future; it's kind of a big deal.There is a variety of
mining pool reward methods. Among other things, they differ in the trade-off they choose between several performance metrics, or in other words, their position on the
reward method triangle. In particular there is a spectrum of the amount of risk taken by the pool operator, from
PPLNS where there is no risk to PPS where the risk is completely assumed by the operator. Higher-risk methods allow better variance and maturity time, but the operator will demand more fees to compensate for his risk.
Low-risk methods are popular now, but I don't believe they will stay with us forever. They are more complicated and it's difficult for miners to figure out exactly how much they should get and verify that they get it, which has given rise to a vigilant
neighbourhood pool watch. That is fine if the complication is necessary, but as I intend to show, it is not; we can have a well-performing system with the pure simplicity of PPS. Furthermore, low-risk methods were designed with a constant block reward in mind. Going forward, the coinbase reward will be negligible, and the reward will consist completely of transaction fees, which are variable as more transactions are added or placed in published blocks. The methods can be adapted to remain hopping-proof even in this scenario, but they then no longer pose zero risk for the operator. These methods will look so much like PPS that we may as well just go with PPS.
For understanding the problem that I'd like to solve for PPS, it is illustrative to consider the no-risk methods (such as PPLNS) a bit more. With a choice of parameter, we can determine the trade-off between variance, the difference between what miners get in practice and what they should expect on average, and maturity time, the time it takes until miners get their payments. You can improve one at the cost of the other, but the only way to improve both is to have a bigger pool. A big pool can offer better performance to its miners, causing a "the rich get richer, the poor get poorer" effect - miners will flock towards the biggest pools, making them even bigger and resulting in most of the hashrate concentrated in a few large pools. This is very bad for the Bitcoin network health, as it makes it easier to maliciously obtain majority hashrate to attack the network with double spends, transaction denial of service and so on.
I have offered a solution to this in
Mine in multiple pools to reduce variance - mining with several pools simultaneously, splitting your hashrate in proportion to the size of each pool. This allows enjoying performance equivalent to a pool of the combined size of all pools, which is better than any single pool, however large; and the macroscopic effect of pursuing the best performance is maintaining the current size distribution, so pools can compete on their fundamental merits and small pools are still attractive.
But as mentioned, I don't believe PPLNS is long for this world, and a similar problem exists for PPS which this doesn't solve. In
Analysis of Bitcoin Pooled Mining Reward Systems (appendix "Safety nets for PPS pools"), I analyzed the requirements for a PPS pool to minimize its chance of bankruptcy. For every share submitted to a pool, there is a chance of p to find a block, in which case the pool gets a block reward of B; this means the expectation of the pool's reward per share is pB, and the variance is pB^2. We will denote the ratio between variance and expectation by t; in this case t=B. I have shown that the probability of bankruptcy is exp (-2fR/t), where f is the pool's fee and R is the pool's reserve. This means that to function normally (and without exhorbitant fees) the pool must have a fairly large reserve - agents without sufficient capital are out of this game.
Another way to look at this, different from probabilities of bankruptcy, is considering the expectation of a utility function logarithmic in net worth. If the pool's current net worth is R, then its gain from a reward of expectation E and variance V is roughly E-V/R. The variance creates an additional cost which the pool must compensate with a fee. The minimal fee must satisfy fE=V/R, or f = (V/E)/R = t/R. Bigger pools, owned by an agent with a higher net worth, are less sensitive to risk and can afford lower fees, again pushing out smaller agents.
Having miners split their hashrate among several PPS pools is completely useless for combating this. For every share the pool does get, the expected reward is still pB and the variance is still pB^2, meaning f = B/R, which is still high unless R is large. Changing the share difficulty also has no effect.
To explain my proposed solution, it is necessary to understand the concept of smart miners, also known as split pools. In traditional pools, the pool serves two roles, a network node that builds blocks and assigns work, and an insurance agent that reduces the variance of miners.
However, these two agents needn't be the same. A smart miner contacts separately a node that assigns work, and an insurance agent to smooth out payments. (I will refer to such insurance agents as "pools" as they are the more important component of traditional pools.) The pool gives the miner a Bitcoin address to which it wishes to collect block rewards. The node builds a block with all transactions but the generation transaction, and gives the miner a block header (without Merkle root and nonce) and a "complement branch", a set of hashes (the number of which is the depth of the tree, logarithmic in number of transactions) which, combined with the generation transaction, leads to a Merkle branch going all the way to the root. The miner builds a generation transaction (with output going to the pool's address) and calculates the root; he then hashes with different nonces. If he finds a hash matching the share difficulty, he submits the Merkle branch and the header to the pool; if he finds a hash matching the block difficulty, he also submits it to the node to build a complete block and broadcast it.
For every share the miner submits to the pool, he is rewarded just like in traditional pools. The Merkle branch proves that he has done work which has probability p to result in a block giving the pool B, just like with any other pool. The node doesn't need to be big, just enough to be able to run a network node, so there can be many such nodes offering their services.
It can be asked, how does the pool know that the complete block which credits it will be broadcast if found, or that "the rest of the block" even exists and it is not just a random set of hashes. It doesn't; but this is no different than the current situation with block withholding attacks. The miner can't fake work or reuse work, so he has incentive to lie only in some edge cases; the node will typically be involved in finding several such blocks over its career (unlike a miner which might never find a block in his lifetime), so it can demonstrate its trustworthiness in actually building blocks and broadcasting them. There will always be some small percentage of withholding, but it can be assessed over time and be accounted for in fees.
So we've separated pools from building blocks, and in the case of PPS, the pool will pay out (1-f)pB for every share it gets, as it gives it a probability of p to get a reward of B. The problem still remains, how to reduce the risk of the pool. And the solution is simply to let the miner
credit several different pools in his generation transaction. He collects addresses from several pools, and in the generation transaction he builds, he pays out b1 to pool1 1, b2 to pool 2 and so on, for a total of B. When he finds a share, he submits it to all pools; a pool that sees that it was credited with b, will pay him pb.
And here's the crux: A share has a probability of p to reward the pool with b, so the expected reward is pb and the variance is pb^2. The ratio is t=b, and since b<B, the ratio is better than before. If we have n pools, each with a net worth of R, with the naive method each would demand a fee of t/R = B/R. but if the miner splits the transaction between the pools, each has a ratio of b = B/n, meaning it is satisfied with a fee of t/R = B/(nR), an improvement by a factor of n.
More generally, PPS pools have traditionally taken a fee as a fraction of the expected gain, because there was no way to decouple it from the variance. But now we can, so the fee policy should be different. The value of a share to the pool is pb-pb^2/R, so that's exactly what it will pay for it - the fee will be pb^2/R. (I'm disregarding fees for the service itself, which should be quite low and are separate). This is the recommendation based on the pool's net worth, but of course the pool can choose a value of R how it sees fit regardless of what it considers its "net worth". Each pool will publish its fee policy; if there are pools of size R1, R2, ..., the miner can split the reward b1, b2, ... for a total fee of pb1^2/R1 + pb2^2/R2 + ... . It can be shown that the minimal fee is obtained when each bi is proportional to Ri, and then the total fee will be pB^2/(R1+R2+...), just like mining with a single huge pool with reserve equal to the total of all reserves.
And again, this allows every pool, however small, to participate; it will simply obtain a smaller portion of each block reward, so it doesn't get more risk than it can handle. There can come a point where a pool is so small that considering it isn't worth the resource cost of broadcasting messages; however, technology advancements will help push that limit. The total fee for a pool will likely have 3 components - risk fee, service fee and resource fee (proportional to b^2, b and 1 respectively).
And of course, all these negotiations between miner, pools and node are done in software, which can also track the number of found shares and easily compare the reward it should get with the reward in practice. The miner just plugs and plays, and can easily verify the results.
I used to call this arrangement by a variety of names, but I will now simply refer to it as "Multi-PPS".
Trivia: I do my best thinking while traveling, apparently. I invented
DGM while sitting in a train. I invented multi-PPS while sitting in an airplane, thinking about the vision I wanted to present for the future of pooled mining in my talk, and realizing it was very different from what I originally thought. And the inspiration to write this down now, after 3 months of procrastination, also came while sitting in a train.
