What do you think about Ypool?

[craslovell]

Just found http://ypool.net/

Does anybody know if this is scam and/or if the cpu miner does work?

It only supports win32 atm. So not a really alternative so far.

10 blocks found per day for the only pool is extremely low...

either this is a scam, or someone already coded gpu miners...or both.

There are almost certainly people running GPU miners in secret right now. I would not say this pool is a scam, it just needs to work out all the kinks.

Setting up an XPM pool and finding a good way to evenly distribute the workload between miners is a lot more difficult than the configuration of the other pools in existence right now. It's all new territory at this time.

[craslovell]

I found this explanation from Koooooj over at bitcointalk about one of the potential issues with pooled XPM mining. The explanation seems sensible to me. Are there any ways Ypool plans to solve this exploit?

Quote from: Koooooj on Today at 05: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.

[jh00]

craslovell, this guy is kind of rushing on us. He is right about the issue but considering that I am the only one developing the pool server and pool miner (well I got some help now) it's obvious that I can barely keep up with the work, yet I also have to stay on top with the performance updates of other miners. I have to set priorities and as many are likely aware, I have mentioned several times that the pool is still beta/experimental. The exploit he describes is not really unstoppable. Currently I record the difficulty of every single share submitted. In theory I can check the ratio of short/long chains and get a hint about the probability of the user cheating. However, using this method I cannot detect if someone sends only a small ratio of unfair shares. It's all a temporary solution.

On the bright side, I think I found a more permanent solution to this problem that will be good enough for a while. You can read about it in my response in the original reddit thread here.

[craslovell]

craslovell, this guy is kind of rushing on us. He is right about the issue but considering that I am the only one developing the pool server and pool miner (well I got some help now) it's obvious that I can barely keep up with the work, yet I also have to stay on top with the performance updates of other miners. I have to set priorities and as many are likely aware, I have mentioned several times that the pool is still beta/experimental. The exploit he describes is not really unstoppable. Currently I record the difficulty of every single share submitted. In theory I can check the ratio of short/long chains and get a hint about the probability of the user cheating. However, using this method I cannot detect if someone sends only a small ratio of unfair shares. It's all a temporary solution.

On the bright side, I think I found a more permanent solution to this problem that will be good enough for a while. You can read about it in my response in the original reddit thread here.

jh00,

Thank you for the explanation. I am not trying to detract from your pool, I am simply attempting to point out one of the challenges to fair pool mining with primecoin. I support your efforts to make the pool solid and fair. If I had any clue when it comes to coding I would be trying to assist myself. Unfortunately I am close to clueless. The furthest I ever got with it in school was making a basic store calculator in c++ 

Please post updates/fixes to the pool in this thread if you can. It will be a good hub of information for users here.

EDIT: Perhaps it would be better to make a new thread under your name.

[jh00]

EDIT: Perhaps it would be better to make a new thread under your name.

I will do so once I consider our pool stable, secure and able to scale without performance problems. We have already much more workers than we should have for the current server architecture.

[Sunny King]

Hi jh00,

  I don't know if you can prevent miner cheating by asking for sieve info but I think there is another solution that's possible.

  Instead of the pool setting a fixed share difficulty, it would check all lengths above a minimum share difficulty. Let's say the minimum share difficulty is 8. So any 8-chain, 9-chain, 10-chain etc are all submitted as pool share, but the pool will set different share values for different length chains.

  Let's assume that without proper sieving the transition ratio is 30, meaning a (n+1)-chain is 30 times rarer than n-chain. With proper sieving the transition ratio becomes 10. These are just example figures to illustrate the approach.

  From pool's point of view, the different length chain shares are treated differently. Thus for the 9-chain share it would reward a share value x times more than an 8-chain share, instead of the current scheme of paying same share value for all length-chain shares. x is a ratio to be determined by the pool to thwart cheating, based on the transition ratios above of the honest miner and cheating miner.

  This would mean that there is still luck factor when mining with the pool, as whoever mines the longer chain share gets paid more. However cheating on the sieve then probably would not gain the miner more income on average.

  Just some food for thoughts.

  Keep the good work up 

craslovell, this guy is kind of rushing on us. He is right about the issue but considering that I am the only one developing the pool server and pool miner (well I got some help now) it's obvious that I can barely keep up with the work, yet I also have to stay on top with the performance updates of other miners. I have to set priorities and as many are likely aware, I have mentioned several times that the pool is still beta/experimental. The exploit he describes is not really unstoppable. Currently I record the difficulty of every single share submitted. In theory I can check the ratio of short/long chains and get a hint about the probability of the user cheating. However, using this method I cannot detect if someone sends only a small ratio of unfair shares. It's all a temporary solution.

On the bright side, I think I found a more permanent solution to this problem that will be good enough for a while. You can read about it in my response in the original reddit thread here.

[psyc]

hi, i try to mining pool but I often receive the message "server rejected share<blockheight: xxxxx/xxxxx nBits:xxxx> why?   
sorry for my bad english

[bcp19]

hi, i try to mining pool but I often receive the message "server rejected share<blockheight: xxxxx/xxxxx nBits:xxxx> why?   
sorry for my bad english

One thing you need to understand, every time a new block is found, results from the previous block are rejected (because they are stale).  Since Primecoin is neither SHA nor Scrypt, the current getwork and stratum protocols other coins use are worthless and a new protocol needs to be built.  As this is refined and improved, there will be fewer rejects, but with ~20 seconds a block, some rejects will be a given.

Maybe a better way to put it... look at bitcoin.  10 minutes average per block mean 10's of millions of shares per block.  the few rejects you receive when a new block is found is paltry compared to the accepted shares.  Hope this helps.

[psyc]

hi, i try to mining pool but I often receive the message "server rejected share<blockheight: xxxxx/xxxxx nBits:xxxx> why?   
sorry for my bad english

One thing you need to understand, every time a new block is found, results from the previous block are rejected (because they are stale).  Since Primecoin is neither SHA nor Scrypt, the current getwork and stratum protocols other coins use are worthless and a new protocol needs to be built.  As this is refined and improved, there will be fewer rejects, but with ~20 seconds a block, some rejects will be a given.

Maybe a better way to put it... look at bitcoin.  10 minutes average per block mean 10's of millions of shares per block.  the few rejects you receive when a new block is found is paltry compared to the accepted shares.  Hope this helps.

thanks for the explanation 

[PPCoinFX]

Updated Primeminer v3.0 v3.1 v3.2 released.

Now using x.pushthrough protocol.

Example usage: jhPrimeMiner.exe -t <number of cores> -o http://ypool.net:10034 -u <username>.<workername> -p <password>

Pool found a couple more blocks as well.

[FuzzyBear]

Updated Primeminer v3.0 v3.1 released.

Now using x.pushthrough protocol.

Example usage: jhPrimeMiner.exe -t <number of cores> -o http://ypool.net:10034 -u <username>.<workername> -p <password>

Pool found a couple more blocks as well.

Yeah pool looks to be working really nice now lots of blocks coming in and miner is real nice and stable just my dam PC's that get too hot now

FuzzyBear

[craslovell]

I am giving a shot now. Hopefully all goes well 

[bcp19]

Miner version 3.2 is out now

[Sunny King]

Gratz ypool I just checked 5% blocks and 3000+ workers. I never expected a pool like this in the 2nd week of primecoin 

[FuzzyBear]

Gratz ypool I just checked 5% blocks and 3000+ workers. I never expected a pool like this in the 2nd week of primecoin 

dang !!! 3000+ workers!! was 220 yesterday... no wonder my amount per block dropped

Gtz though on the pool

FuzzyBear