What do you think about Ypool?

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 :slight_smile:

[quote=“jh00, post:18, topic:246”]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.[/quote]

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

[quote=“psyc, post:22, topic:246”]hi, i try to mining pool but I often receive the message "server rejected share<blockheight: xxxxx/xxxxx nBits:xxxx> why? :frowning:
sorry for my bad english[/quote]
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.

[quote=“bcp19, post:23, topic:246”][quote=“psyc, post:22, topic:246”]hi, i try to mining pool but I often receive the message "server rejected share<blockheight: xxxxx/xxxxx nBits:xxxx> why? :frowning:
sorry for my bad english[/quote]
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.[/quote]

thanks for the explanation :slight_smile:

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

Now using x.pushthrough protocol.

Example usage: jhPrimeMiner.exe -t -o http://ypool.net:10034 -u . -p

Pool found a couple more blocks as well.

[quote=“PPCoinFX, post:25, topic:246”]Updated Primeminer v3.0 v3.1 released.

Now using x.pushthrough protocol.

Example usage: jhPrimeMiner.exe -t -o http://ypool.net:10034 -u . -p

Pool found a couple more blocks as well.[/quote]

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

FuzzyBear

I am giving a shot now. Hopefully all goes well :slight_smile:

Miner version 3.2 is out now

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

dang !!! 3000+ workers!! was 220 yesterday… no wonder my amount per block dropped :stuck_out_tongue:

Gtz though on the pool :smiley:

FuzzyBear

Thanks! But you can imagine I didn’t sleep much in the past two weeks :stuck_out_tongue_winking_eye: It’s a fun project however, but the demand is 100 times larger than expected.

Arg I join up and a few hours later I find a block >:(

No worries though, pool seems to be running well. Client has not crashed on me since I started it.

Thanks! But you can imagine I didn’t sleep much in the past two weeks :stuck_out_tongue_winking_eye: It’s a fun project however, but the demand is 100 times larger than expected.[/quote]
Kudos for fixing the miner, the last version was frustrating … now to give you more work: Can you incorporate that speed into your miner: https://bitcointalk.org/index.php?topic=255782.0 ?

WOW, I didn’t even realize… there was something like 300 workers a day before that!

I wonder if its actually possible to use the same processor to solo mine and pool, like 3 cores solo, 3 cores pool?

Shouldn´t be a problem as long as the miner for the pool supports to reduce the number of threads. The wallet does support this

In your case: setgenerate true 3

Sweet I will give that a try! Cheers :wink:

control+shift+esc

Go to the ypool miner process and right click, hit affinity and assign desired cores.

Cool trick, didnt know that one. Still, need a windows for that :wink:

Almost 4000 workers now! 8)