Network latency, stale shares, and p2pool

[maaku]

My understanding is that p2pool operates an alternative blockchain with a 10-second target interval, where each found block constitutes 1 share. Somewhat coincidentally I have previously looked at the properties of an altchain with 10-second intervals, and what I found was that the network latency/p2p propagation time was a significant factor. On bitcoin proper it takes about 1.9 seconds for a newly minted block to find its way to all the bitcoin peers. Assuming you're solo mining with long-poll enabled, that means you're working on a stale block 0.15% of the time, on average (since you can assume the time it takes a block to reach just you is half the latency). But on a 10-second round, that likelihood is now 9%, a couple of multiples larger than even the most ostentatious pool operator fees.

Is this accurate, or am I doing something wrong with my math?

EDIT: I can't find any reorglog statistics for p2pool online, which we could use to determine p2pool's network latency... if someone has kept track of this, let me know.

EDIT2: P2Pool is safe to use! My analysis above, while not incorrect, is incomplete and only half of the story. The amount paid per share that *does* make it into the share chain is also approximately increased by a corresponding amount, negating the effect due to stale work.

[1714794426]

1714794426

[1714794426]

1714794426

[Syke]

P2pool shares aren't a blockchain. They don't invalidate each other. Until a real Bitcoin block is solved, all the shares accumulate and are valid.

[maaku]

That's not how the bitcoin wiki describes p2pool...

P2Pool shares form a "sharechain" with each share referencing the previous share's hash... The chain continuously regulates its target to keep generation around one share every ten seconds, just as Bitcoin regulates it to generate one block every ten minutes.

The wiki also says:

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 60 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is PPLNS only your stale rate relative to other nodes is relevant; the absolute rate is not.

Which is misleading. Stales don't affect your payout relative to other p2pool nodes (assuming everyone is equally well connected, which is actually not a good assumption), but they do affect the overall payout per unit of work crunched of p2pool vs. other pools.

EDIT: clarified wording

[forrestv]

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 60 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is PPLNS only your stale rate relative to other nodes is relevant; the absolute rate is not.

Which is misleading. Stales don't affect your payout relative to other p2pool nodes (assuming everyone is equally well connected, which is actually not a good assumption), but they do affect the overall payout per unit of work crunched of p2pool vs. other pools.

No, it isn't misleading. It doesn't affect the payout per unit of worked as compared to other pools because stale shares on P2Pool can still be valid block solutions. P2Pool's effective block solving ability is exactly equal to an equally sized normal pool.

[maaku]

Stale/orphan shares on YourTraditionalPool can also be valid block solutions. That's not the issue (the chance of your orphan block being a valid solution is just under 0.15%). The issue is that stale data occurs approx. every 10 minutes for a traditional pool, but every 10 seconds for p2pool while the network latency presumably remains the same (and therefore is of 60x more consequence). The discrepancy is because traditional pool operators are not required to linearly order shares into an auxiliary blockchain as p2pool does.

Put differently, when some other miner finds a share in a traditional pool, I don't have to have to update my unit of work unless that share is a valid bitcoin block solution. But with p2pool I do--every time--and often enough to where network latency has a significant dampening effect. Traditional pools have a "wasted work" overhead of about 0.15%, but as this effect is small and nearly the same across the board, it's not something we talk about much. However p2pool is unique in requiring synchronization 60x as often, making this effect very real, measurable, and a significant factor.

Put differently again, if my overclocked GPU is reporting 400MH/s and I signed up for deepbit, to name one pool just for the sake of argument, my useful contribution--after subtracting time spent stale data that doesn't have a chance of being accepted--would be closer to 399.4MH/s. That's such a small difference that it's easily lost in the noise and hardly worth talking about... except that with p2pool, my useful contribution would be 356MH/s--a full 43MH/s less. That is significant, and worth complaining about.


BTW, there is a solution, although it is not easy: create a procedure within p2pool for the merging of divergent/orphan chains.


EDIT: Put even more simply: what happens to orphan "blocks"/shares in p2pool? Therein lies the problem.

[Asiketeisc]

P2Pool only uses the share chain to decide how to split the block reward. As long as everybody has approximately the same stale rate, it makes no difference. Actual Bitcoin block solutions are still submitted to the Bitcoin network even if they're no longer valid in the P2Pool chain.

[maaku]

It does make a difference. What happens to your share if it becomes an orphan block on the share chain? Other miners work on the competing block and you lose out on any dividends from your share. If my analysis in the OP is correct, this should be happening an alarming 9% of the time. A traditional pool, on the other hand, would count both shares as valid and pay dividends to both miners.

Again, if p2pool implemented a means of "merging" divergent share chains, that would adequately address this problem. Until then and ignoring p2pool subsidies, it's more profitable to mine an (honest) traditional pool.

[paraipan]

watching...

[forrestv]

Don't worry; your analysis isn't correct.

You've already admitted that P2Pool as a whole has comparable block-finding ability to other pools, so the only thing you could be arguing for is that P2Pool distributes payouts unfairly. It doesn't, because it uses a fair PPLNS based on the amount of work you have in the sharechain.

If P2Pool really were, by its nature, 9% less efficient than other pools, do you really think it would be at all popular? Do you think people who were okay solo mining would switch?

Merging shares is not required provided that everyone has close stale rates (which isn't actually true, but most people with bad stale rates have something misconfigured).

[twmz]

It does make a difference.

If you believe that to be true, please present some math to explain it.  I believe it doesn't make a difference. I may be wrong but you aren't convincing me without a more detailed explanation of your concern.

Here are two scenarios.  In both, I am mining and you are mining. In a given period of time, I am mining at 4 GH/s and find 1000 shares.  You are mining at 8 GH/s and find 2000 shares.

Scenario 1 : P2Pool (9% of shares are stale)

Of the 1000 shares I found, 90 were stale.  So I found 910 valid shares.
Of the 2000 shares you found, 180 were stale.  So you found 1820 valid shares.

I found 910 out of (910 + 1820) total shares.  That is 910/2730 or 33.333% of shares and so I will get 33.333% of each block payment.  That is, not coincidentally, the same as the the percentage of my hashrate (4 GH/s) vs the overall pool hashrate (12 GH/s).

Scenario 2: Normal Pool (let's say 0.1% of shares are stale)

Of the 1000 shares I found, 1 was stale.  So I found 999 valid shares.
Of the 2000 shares you found, 2 were stale.  So you found 1998 valid shares.

I found 999 out of (999 + 1998) total shares.  That is 999/2997 or 33.333% of shares and so I will get 33.333% of each block payment.  That is, not coincidentally, the same as the the percentage of my hashrate (4 GH/s) vs the overall pool hashrate (12 GH/s).

Conclusion

Rate of stales doesn't matter as long as everyone is getting them with the same frequency and as long as the frequency of blocks being found is not reduced (which you agree isn't a concern in the p2pool case).

[Gabi]

Note that on p2pool stale shares are still valid for finding a block.

If i mine with 1GH/s and i have a 10% stale rate, one think that "mmhh i'm wasting 0.1ghash/s, better i switch to another pool"

But it's not true

[maaku]

Don't worry; your analysis isn't correct.

You've already admitted that P2Pool as a whole has comparable block-finding ability to other pools, so the only thing you could be arguing for is that P2Pool distributes payouts unfairly. It doesn't, because it uses a fair PPLNS based on the amount of work you have in the sharechain.

And I see now that is the other half of the equation that I was missing. PPLNS pays the last N shares of the share chain, so a high stale rate means that shares which do make it into the share chain stay within the PPLNS dividend window for a longer period of time, so that on average it balances out. It's interesting to note though that the two effects are not exactly the same from the perspective of an individual miner: the hit due to stale rate depends on their individual setup, particularly their network and graph connectivity, while the “bonus” due to PPLNS is based on the whole network's average stale rate. In practice well connected miners would be taxing a small but measurable amount from miners that haven't bothered to "fix" their stale ratio.

But that's leaps and bounds different from my claim in the OP, and I apologize for the unintentional (though well-meaning) FUD. I'll update the OP accordingly.