Now consider the rule defined by those 3 lines I was talking about. It states "If a share (S) is based on stale block, mine on its parent (P)." (That's what "Punishing for block-stale / Jumping to ..." log message is about.) If a miner (either intentionally or because of slow bitcoind) disrespects this rule, not only he loses nothing, but may also eventually profit from it! Really, his share A (a child of block-stale share S, which is punished by the rest of the network) is 1 share ahead of "proper" miner's share B, which is P's child. As a result, A will have priority over B even if B is found earlier!
Should I report a bug on GitHub?
You should. But read below why I think it's not high priority.
2 cases in your example:
- local bitcoind lagging: miner is punished most of the time so it is prevented to benefit from worthless work as intended and is motivated to upgrade his/her configuration
- node trying to make his share more resilient by avoiding to build on the parent share
In the "more resilient attack" the node can only attack after one out of 20 shares (30s share interval with 10mn block interval) if and only if it is from a slow node producing a stale share (assuming we don't have nodes more than 30-60s behind the Bitcoin network able to make 2 successive stale shares).
- if another node finds a share before him he will automatically switch to it as building on either fork doesn't give him any benefit anymore
- if he finds a share before the rest of the network, he won't have gained anything (he has as much chances of that happening when mining on the parent share)
- the only gain is when he finds a share that collides with another : there he will be sure to win instead of having ~50% chances
.
So someone trying this attack will get benefit for less than 5% (1 in 20 at most, probably far less) of his expected DOA+Orphan rate (which seems to be ~10% since we switched to a 30s share interval) and this benefit will be ~50%.
So in the most pathological case where 100% of the network produces stale shares (built with the previous block), the expected benefit is only 50% of 10% of 5% : 0.25%.
Most nodes probably don't produce stale shares, so this is more likely a ~0.1% advantage.
Now what is the attacker losing? If you don't punish slow nodes you are hurting yourself as much as the rest of the network by validating wasted work. The exception is the slow node which is grateful to be paid for worthless work.
For every gained share you are validating one worthless share. If everyone did this, everyone would lose money to worthless shares producers instead of gaining 0.1%. Now it's too late for me to try to estimate how much is lost but disabling the protection might not be a good idea, especially if many are doing it. It probably would end in a "tragedy of the commons": you can gain a bit by doing it, but when everyone does it, everyone loses.
Allowing worthless work allows it to rise without limits: if there are very slow bitcoinds with very high hashrate they could make 2 or more consecutive stale shares a frequent occasion and rise the worthless hashrate to 10 or more percent of the whole pool.
One solution might be to ignore stale shares when comparing the different sharechain forks. People disabling the protection would get no benefit at all.
In the meanwhile, advocating to remove the protection is an attack on P2Pool, please stop doing it unless you want to participate in your own reduced income.[/list]