Post
Topic
Board Pools
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
by
belcher
on 04/10/2017, 22:52:31 UTC
Has anybody thought about in detail how adding the uncles scheme to p2pool would work?

It was mentioned in the original bitcointalk thread about uncles in 2013 here and here. And also by jtoomim a few months ago here

But I haven't been able to find more details (or even mentions) than those. I've got a couple of ideas but it's good to read everything that's been written about it beforehand.


If uncles was applied to bitcoin then special care would have to be taken to make sure a transaction in an uncle doesn't conflict with a transaction in the main chain. This doesn't apply to p2pool's sharechain because the shares can't conflict with each other in the same way, each share just gets added to the total work that the hasher did. This is quite a cool property of applying uncles to p2pool.

If uncles are added then I think the share interval could be reduced even more to (say) 15 seconds. There'd be no more orphans at all. This would reduce the difficulty (by a constant factor but still) which would mean if p2pool gets really big then small hashers can still solve shares fairly often.


Another problem with the existing algorithm for choosing which share to base work off of is that all shares are treated the same, regardless of their difficulty, which makes low-diff shares have an advantage for selfish mining attacks. Large-diff shares contribute more work to p2pool, so they should have a greater chance of winning an orphan race, ceteris paribus. But you can't just pick the highest-diff share of all shares in an orphan race, since that would cause a race-to-the-top scenario where the optimal difficulty to use for your shares is the highest diff that a competitor uses plus one. That would also allow a selfish miner to reliably win orphan races against siblings: instead of working on a child share of the best known share, you could just orphan it by creating a sibling with +1 difficulty. So it needs to be probabilistic.

Another way of solving this apart from being probabilistic is to limit the difficulty that hashers can mine on. Only allow p2pool hashers to mine 1x difficulty, 10x difficulty, 100x difficulty and 1000x difficulty. Then it becomes impossible for a bad hasher to just mine difficulty + 1, they can only mine difficulty x 10.

Of course, with the scheme of adding uncles to p2pool there totally stop being orphans so these kind of difficulty games don't lead to extra profit.