Imagine if I am an evil pool with 310 GH/s and you are the honest p2pool miners with 280 GH/s. I hop over to p2pool with my pool and start mining on top of your shares, entering the share chain. You then try to build shares on top of mine, but every time you do I create a fork. I only build shares on top of my own shares. My forks are always longer than yours, so you never get paid. I am now using 310 GH/s and getting paid for 590 GH/s. You get nothing.
How would the good miners get nothing?It does look like an exploit is possible but the exploit is non-economic or minimally economic. 51% attacks in Bitcoin are powerful because you can reverse prior transactions. That isn't possible in p2pool. Attacker could reject all other shares and only build on his chain but that only affects future shares.
There are a couple things that make that of limited value:
a) It will take 24 hours (at 51%) to get full value. Attacker can't build the chain any faster and it will take 8640 shares to remove all prior "good" shares from the chain by attrition. If attacker had been mining "good" (to avoid a noticeable instant doubling of hash power) then the effective hashpower of the attack chain would be half and it would take 48 hours to achieve full effect. p2pool could keep a longer history to extend the full value time.
b) It is immediately obvious. all good nodes would see 100% reject rate. The node currently doesn't have a "failsafe" but imlementing a max global orphaned in last x minutes check could make automated detection. If global orphan rate spikes node stops issuing work and miners drop back to backup pools. In the case of a hybrid pool it would drop to "conventional mode" (albeit with increased variance).
c) Attack has limited economic value as to achieve full value (200% pps) attacker would need to sustain the attack for 24/48 hours without any good miners dropping out.
d) Attacker can't work in secret. In Bitcoin 51% attack since the goal is reversing a prior transaction an attacker can work days or even weeks in secret building an attack chain. That doesn't work here because the value of any shares is "cashed out" when a block is found. Every second attacker doesn't publish the attack chain is a second p2pool could find a block and make all the attack work worthless.
Still I am glad you brought it up. A failsafe based on global orphan rate is a good feature to add to the node. Also, I don't see a way to control the difficulty - it's based on the share chain.
...
the 10 second block intervals could be turned into 10 minutes,
Difficulty can be controlled but it is linked to the LP interval.
Difficulty = (LP interval) * (p2pool network hashing power) / (2^32)
Right now p2pool uses a target LP interval of 10 seconds and has ~300 GH/s that gives it a share difficulty of ~690.
As a side note this is no different than Bitcoin. Bitcoin targets a 10 minute block interval and has roughly 9.5 TH of hashing power (at the last adjustment) so it has a difficulty of ~1.3 million.
So (by consensus of hashing power) one could choose another interval and to support sub pools someday p2pool will likely need to have a longer interval. 10 minutes is far too long though as difficulty for a share would be a fraction of Bitcoin = p2pool hashing power. Reverse way to look at it is p2pool lowers share difficulty by a) having less hashing power than bitcoind network and b) having a shorter interval.
A LP interval of 60 sec would require 6x the difficulty relative today for the same hashing power. At say 1.5 TH/s that would mean a difficulty of ~21,000. Very high but a tiny fraction of the block difficulty that pools currently shoot for (and the variance that comes with it).
