yPool.net XPM Pooled CPU Mining!!!

[mastadonballs]

so ypool.net offers pooled cpu mining with their client.

I'm testing the waters and it seems to work and submit shares... but i don't think the miner client is as efficient as the hp4 release by mikaelh.

Anyone try this mining pool?

[1713308908]

1713308908

[vingaard]

I've started with this pool right now... 

[alexxy]

It dont have linux client at all. And source code of windows client is non portable

[funnow]

I have tried yesterday, but with the primeminer 0.2.4 version I'm getting more rejected share than accepted. So I think is still lot to do.

[Tripjammer]

I have tried yesterday, but with the primeminer 0.2.4 version I'm getting more rejected share than accepted. So I think is still lot to do.

Where is version 0.2.4? I thought it was 0.2.1?

[erk]

I have tried yesterday, but with the primeminer 0.2.4 version I'm getting more rejected share than accepted. So I think is still lot to do.

Where is version 0.2.4? I thought it was 0.2.1?

The jhprimeminer v0.21 keeps stopping for me on Windows 7, have to Ctrl-C and restart it often. Very unreliable.

[bbxx]

i was mining on i5 3570k 12hours. 1.15xpm as result total.

switched to solo, got one block within same time.

i wrote to support to lower payment treshold, no success

~ 230 users x <2xpm ~200 xpm

so 100% donation from me.

[Koooooj]

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.

[TheSwede75]

Tried it for 24 hours with 8k ppm and got 0.8 immature coins. Pooled mining? More like highway robbery alpha pool..

[Kyune]

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.

[craslovell]

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.

[Kyune]

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.

[tadakaluri]

The Pooler Client is not working on my system (i5 2500 with windows 7 SP1)

[mistercoin]

When I picture Primecoin pooling in my head, I see a bunch of networked CPU's all digging at one block or prime and solving it as a team then moving to the next. Is this what pooling does, or is this what needs to be done in order for Primecoin pooling to work. Im curious

[gatra]

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.

It's not like that. A process can start 2 threads that run on 2 CPUs and it can trust it's threads. A pool cannot trust its miners: some will try to steal/take advantage. So it's a different problem, it's not as simple as subdividing  the work

[Rubberduckie]

i was mining on i5 3570k 12hours. 1.15xpm as result total.

switched to solo, got one block within same time.

i wrote to support to lower payment treshold, no success

~ 230 users x <2xpm ~200 xpm

so 100% donation from me.

I mined with my i7 for 24 hours and got 1.5 XPM , switched back to solo and get an average 1 block a day.

Also can't withdraw my coins because of the 2 XPM threshold

Either the pool miner is very inefficient or something else is amiss

[Koooooj]

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.

[markm]

Maybe no pools is good.

Just stick a USB ASIC miner in the back of your PC and forget about it until next birthday or holiday you receive another such party-favour with which you do the same. If one of them wins some year, buy one or more such party-favours to give to friends. On poker night, let who-ever can sign a message using more new winning addresses than any of the others be first dealer. Wean friends and family from buying lottery tickets to buying these party-favours. Etc.

Isn't decentralisation meant to be a feature, and pools dangerous concentrations of power or dangerous precedents that could lead to dangerous concentrations of power?

-MarkM-

[funnow]

Latest stable miner is v 0.32. Working 100% no stale share get 26 shares in 30 minutes (Q6600).

[Kujmandosz]

Latest stable miner is v 0.32. Working 100% no stale share get 26 shares in 30 minutes (Q6600).

yeah. everybody come and join the pool. finally you would get some xpm.