Quote from: Kyune on July 19, 2013, 11:23:55 PM

Quote from: craslovell on July 19, 2013, 11:08:00 PM

Quote from: Kyune on July 19, 2013, 10:59:11 PM

Quote from: Koooooj on July 19, 2013, 09:40:09 PM

The miner for ypool can never match the efficiency of a solo miner, and it certainly can't compete with mikaelh's most recent builds. This is because in pooled mining (at least ypool's implementation of it) the miners are paid to produce blocks of a lower-than-network difficulty, as in Bitcoin. This is not a problem in Bitcoin since you can't look for low difficulty shares without looking for high difficulty shares at the same time.

However, in Primecoin it is very possible to tune ones search for shorter chains. For example if, after the sieve, you find a collection of 7 numbers that are in the form of a chain (e.g. H-1, 2H-1, 4H-1, 8H-1...) but the number on either side of the chain was proven to be composite then you should not waste time with an expensive primality test on any of the numbers--it will never be a valid share when the network difficulty is 8 or higher. However, if miners are paid to produce shares of difficulty 7 then they should check this chain.

There are a few resolutions to this dilemma. One possibility is that everyone checks all chains that aren't long enough to be network shares but could still be pool shares. This is fair for everyone--nobody has an advantage over anyone else--but it means that fewer blocks are generated overall (everyone is wasting time that doesn't benefit the network). Another possibility is that some people ignore the shorter chains, while others check all chains. This gives an unfair advantage to the people checking the shorter chains--they will produce fewer valid blocks for the pool this way while producing more shares and taking a larger cut of the profits. The final option is if everyone only checks the longer chains while ignoring the shorter ones. This is the solution that gives the highest average payout and is the one that ypool is trying for, but it has the problem that if anyone wants to increase their payout they just have to change a couple lines of code and suddenly they can start taking a higher payout. This is a classic case of the Tragedy of the Commons.

I have explained this attack in detail to (who I think were) the operators of ypool and they have continued to operate. The only case where mining with them is a wise decision is if you are so averse to variance that you are willing to take an enormous cut to your profits (e.g. 50% or more) in exchange for a more regular payout.

Fascinating. So do you think primecoin is going to end up fundamentally incompatible with pooled mining simply because of the nature of the computational work being done for the coin, or are the problems that you have outlined likely only specific to ypool's implementation and solvable by a different and creative approach to parceling out work to pool participants?

If primecoin ultimately became a coin that was considered optimal to GPU mine, but significantly suboptimal to pool mine, that would make it quite the unusual coin, and would leave small miners with no escape from high variance.

I'd say from that explanation the only way one could effectively pool mine without this exploit would be to literally setup their own private pools to operate however many rigs they are mining primecoin with.

Thank you for the insight Koooooj, interesting.

I don't have a deep understanding at all here. But this is particularly interesting because so far we've all, as far as I know, only been using modified internal miners (like mikaelh's). No one has really even solved the problem of parceling out work to two separate CPU's using external miners. But at a basic level, I would think that if there someday exists code allowing 2+ CPUs (or 2+ GPUs) graphics cards in the same system to interface with the same primecoind and mine via external miner, there would have be a way to insert as an intermediary some pool management code to consolidate work and distribute rewards fairly.

Setting up a pool among your own miners gets you nothing. Parceling out work to two separate CPUs doesn't get you much, but it could allow a larger sieve to be more efficient. It all comes down to network bandwidth and latency, which would make a large distributed pool impractical.

I got a reply from the ypool operators and they've made the best suggestion I've seen yet. They would require miners to submit information about the sieve they used, so that the server could check that the shares being submitted are valid shares. Due to the computational demands of executing the sieve they could only check one a small percentage of shares, but if a miner is found to be cheating then they could be evicted from the network and their mining proceeds could be confiscated. Such a system would require miners to establish a certain amount of trust before being allowed to withdraw, but it could be made to work. Not nearly as efficient as Bitcoin pools, but still a viable option.