Please do sic BCX on defenseless little p2pool. I double dog dare you to force it to evolve or die, because pressure makes diamonds. Too bad you can't.
I have no control over BCX.
You seem to be hard of hearing. P2Pool can't be fixed. The specific vulnerability is inherent in the fact that it is decentralized. There is no possible mitigation.
Since your feeble technical abilities are becoming too apparent, let me spell it out for you n00b.
Since P2Pool is decentralized, there is no central party to hide any information. Thus all the information for the pooling has to be public. Thus there is no way to hide the requirements of the block solution. Thus miners know when they've solved a block, and can choose to not share it.
The oblivious shares fix requires a change to the block chain, so that centralized pools can select a secret, then have miners solve a block solution that depends on that secret. Thus the miners never know if their mining share is a block solution or not. P2Pool can't do that, impossible.
Now please get a life and leave me alone.
It sounds like you're trying to get off the forum for a minute or two, so I'm sorry to ask this right now .. but it sounds like what you're saying is that if someone wanted to accomplish what you're describing, then someone could just have to code a program that lets an individual miner know when they've found a solution on a p2pool node .. and then additionally submit it to the network outside of the pool and receive the entire reward themselves rather than get paid pennies from the pool? So they could forego one pool payment for a full block reward, and then carry on in the pool as if nothing happened .. effectively owning that hashrate from the p2pool network for one block relative to themselves? Would software like that in the hands of all the p2pool miners, if such software were to be open sourced and kept up to date, and made to work with standard mining software be possible?
Would that take a lot of work? Or, am I not paying attention again?
Incorrect.
Proof-of-work 101 class is now in session.
A block solution is found by varying the input number to a hash function, until that hash function produces an output that is less than a chosen threshold number (i.e. has a certain number of leading 0 bits). The smaller that threshold, the more attempts at computing the hash with different inputs. Thus that threshold is the difficulty.
So miners have to produce many computations of a hash function before they find a block solution.
With a pool, miners send all[1] their attempts to the pool to get credit for mining. These are called mining "shares". They don't send just those attempts which are the block solution, because then only one miner would get credit and thus no point of having a pool.
So therefor, miners normally know which shares are actually block solutions, and they could choose to withhold from (not send to) the pool those shares which are solutions, thus depriving the pool and the other miners of the income. They also deprive themselves of that income too, because that block solution only applies to the block computed for that specific pool, which has coinbase (block reward) transactions specific for the pool.
Thus withholding the share that is a block solution doesn't gain the miner any extra income and actually costs the miner a very slight amount of income. For example if a miner is producing 1/100 of the hashrate of a pool and withholds its shares which are block solutions, then it loses 1/100 of its income from the pool, but all the other miners also lose 1% of their income too (even though they are not withholding their block solutions). So it hurts all the other miners (e.g. 99 other miners lose 1% in this example too if they all have the same hashrate), so it is a very effective attack because miners will leave for a pool that can pay them 1% more.
The only motivation for the attack is to hurt a pool. So if you have some incentive (monetary or otherwise) to hurt a pool, the share withholding attack is very cost effective means to do it.
To mitigate against the share withholding attack, there is Meni Rosenfeld's oblivious shares proposal. It makes a change to protocol of the block chain so that when a block solution is submitted, it is not a single number, but two numbers. One of those numbers is held in secret by the pool until a block solution is found by the miners, then the two numbers are published by the pool. So the miner can not know if his mining share is a solution or not, because he can not know that secret number until it is published. Only the pool can know. But P2Pool can't avail of that fix, because a decentralized pool can't hide information from its miners, because there is no central party to hide it.
There are potentially mitigation methods other than oblivious shares, but they are heuristic and not absolute. For example, a centralized pool can monitor to see if a miner is never sending block solutions. However given the extremely long times between when a miner would normally find a block solution (up to days, weeks, or months), this becomes extremely problemmatic to implement because miners can hop to different pools within that time frame and expect to get paid for the shares they did submit.
Thus there is no hope for a mitigation for P2Pool. And the heuristic method wouldn't work for P2Pool any way, because IP addresses are plentiful, so the attacker can return under a different IP address if he was detected and blacklisted.
[1] strictly speaking they don't send all, they send those attempts that meet some easier difficulty level than the difficulty the block chain expect.
