The dead shares are not relevant to the bad luck since they can actually solve for a block and result in everyone getting rewarded. P2Pool does look at them and double check if they solve a block before reporting back to cgminer as 'rejected'.
The type of problem we are looking for is exactly the opposite actually.. ie someone who is successfully submitting non-orphan, non-doa shares, but yet not finding any blocks. I can only think of far fetched scenarios under which this might happen but here are two such examples:
1) Someone modifies their p2pool code so they submit shares as normal but never submit a block. Stupid and unlikely, but theoretically possible.2) Some obscure bug in some combination of bitcoind and p2pool, such that rarely a found block fails to be passed on to bitcoind (and yet shares and getworks continue to flow freely, the bug would have to only affect the case where it is an actual block solve)
As an example of 2), if anyone finds this line in your logs, congratulations.. you are the problem
"Error while processing potential block"
About 1):
Every miner working on Bitcoin, no matter if pool, solo or p2pool, has to decide what he wants to deliver before he finds the hash. That is because he has first to decide *what* to hash, then try a billion variances of that data, then, if/when he finds a valid hash, he can not change the data to still have a valid hash.
Exactly that discussion came up some weeks ago about the share-difficulty:
1) decide which share difficulty you work on, i.e. 600 or 2000
2) hash a million nonces, where you are allowed to change a "non-important" part of the data for every try, so you get a different hash result
3) eventually, a hash reaches the (in 1) decided upon) target. that means the first x letters of the hash are zero
4) submit exactly the block you solved (including the exact transactions and random nonce data) to the pool, or bitcoin, or p2pool network
5) profit
what you try:
3) you found a block+nonce combination with a valid hash. lets say you worked on "600 difficulty" data, which you decided in 1). You now luckily and randomly found a hash with much more zeros than needed for "600", in fact it would pass a difficulty of "5000"!
4a) thinking "yay, I want to be paied out for those "5000" now, not just the stinky "600"!
4b) you take that exact block+nonce and edit that "this is a 600 block" to "this is a 5000 block lol"
4c) you hash that block+nonce from 4b)
4d) you get an entirely different hash, which surely won't even pass a "1" target. crash and burn.
I wrote that example about p2pool share difficulty because I find it easier to understand. The point is, you have no chance to change the block+nonce to still have the same or a similar hash. The hash, and the hash only decides upon "jackpot" or "totally worthless". And, of course, all important data is included in the block. Actually that stuff is called coinbase, and, for example, includes the hash of the block before too, among other stuff.
Now when you work on p2pool shares, it includes both the "p2pool share data" as well as the "bitcoin block data". Any manipulation will change the hash, so if you strip the p2pool part of the data you found a valid hash for, the hash does not fit any more.
(I didnt read about the details yet, the combination of both p2pool- and bitcoindata is quite clever, else we couldn't ever solve a bitcoinblock at all.. merge mining is on the same topic)
The only thing you, as a p2pool miner, can do, is drop the valid bitcoin block hash you found. No profit for the p2pool gang, but obviously no profit for you neither. The only effect this has is it will make the "luck" graph look bad. Which is exactly what we are talking about, of course..
Hope that helps, and correct anything I got wrong!
Ente
