Quote from: mustyoshi on July 13, 2013, 05:26:36 AM

Quote from: Koooooj on July 13, 2013, 05:14:32 AM

Quote from: Sunny King on July 09, 2013, 05:18:53 PM

Pool share can be implemented as lower difficulty prime chains, similar to hashcash proof-of-work I think.

I'm not sure this is the case, or at least it is not as simple. With hashcash proof-of-work it is impossible to look for lower difficulty shares without also looking for higher difficulty shares. In Primecoin, on the other hand, as I understand it, one could look for chains of length 7 and find them with much greater frequency than they would find chains of length 7 while looking for chains of length 8 (i.e. pool miners would maximize their share submission by hurting the pool; the tragedy of the commons ensues).

I assume that when the mining algorithm executes it first executes the Sieve of Eratosthenes to build a list of possible primes. If one finds that there is a list of 7 numbers that passed the sieve and form a chain then they could be checked to see if they form a valid share, even if the sieve eliminated the next value, proving that a block of difficulty 8 or higher is impossible from that start (I am assuming a share difficulty of 7 and a network difficulty of 8 or more). A miner optimized for finding valid blocks as fast as possible would save computational time by ignoring the chain of length 7 when the difficulty is 8 or higher, while a miner optimized for finding valid shares would check every chain of primes that passes the sieve that is at least (share length) long.

This could be circumvented by requiring the numbers after the share's chain up to the integral network difficulty to all pass a sieve, but I believe that that would break the requirement that shares be fast to verify by the pool host. Additionally, it would set stringent requirements on how the numbers would have to be sieved which would limit improvements to be made in that area (which seems to be where most of the improvements are being made).

You've made a really innovative coin, Sunny, and I trust you to come up with an innovative solution to this, but it isn't as simple as it may appear at first glance.

My p2pclient will beat this problem. By making a sub blockchain with difficulty one less than the main chain's, payment is based on all the blocks you have submitted during the round. The P2P chain will end up producing many many more primes than the main chain does, maybe somebody will take it upon themselves to create a listening node and just store them, since I won't be making a site for the pool it won't be me, which also means I can make it a no-fee pool.

How does it beat the problem? I think having difficulty one less does not solve it: a miner optimized for the sub blockchain could generate valid blocks which would not pass the sieve if they were working on the main chain. This means they get payed for work easier that what they should be doing, "stealing" from honest miners in the same pool. I guess that if all miners did this "cheat" the problem wouldn't be that serious, however lot's of hardware would be doing "useless" work, something that we were trying to avoid. this gets worse as the difference between the main chain's difficulty and the pool's difficulty gets higher.