Bitcoin Forum

I have been intrigued with this concept since I read a couple weeks ago (yes, it's old news):

Per Meni Rosenfeld:
"If you distribute your hashrate among multiple pools in proportion to their respective total hashrate, your variance will be as if you mine in one pool with the total hashrate of all pools."

I wonder, since my math is crap...
1)  does this apply equally to all payout methods?  PPS, PPLNS, DGM, Slush, etc?  Or is the concept applicable to a specific payout method only?
2) does anyone have results or comments to present based on Meni Rosenfeld's proof?
3) what have other miners done to leverage this or similar concepts?  Such as "I use x many pools, of what pool hash to my hash power ratio, using cgminer --load-balance, etc, resulted in less variance."

Anyone?  Bueller? Gracias!

It's a great idea.  It isn't related to payout method.  Just mine as many pools at the same time as possible so that good luck on one pool offsets bad luck on a different one so that your reach a neutral average all the time.

Sam

Well sort of. Doesn't apply to PPS at all.

Well I guess there is sometimes variance in how I think about things and how they really work :)

To me, the reason to balance between several pools at the same time would be to offset bad luck on one pool with the good luck on another.

Also I don't only consider my mining profitability but also the impact on the pool itself.  So when a pool offers both PPS and another payout which lessens the possibility of a loss to the pool I always choose the other payout method.
Sam

The result is that you get higher "luck"... (Well, less loss.) potential.

The catch is that you are adding more connections to maintain, and SEND/GET with.

The bottom line is this...
1: If one server goes down, without pool-hopping penalty, you continue to make uninterrupted funds. The other GPU's simply process more of the other pools shares until the down-pool comes online again.
2: You do not loose-out for pool-hopping, since you are "Still" there, when a pool comes back online.
3: If one pool has bad luck, chances are, the other pool you are in, just got that block which the other pool did not get. Thus, YOU do not loose from that bad-luck, you continue to get the same value from the other pool.
4: In the end, your gains will be more than the 3% you lost in fees, for participating in any ONE single pool. Your gains will also include, "no losses from down-time", no losses from "pool hopping decay share degrading".

(Pool luck, not the whole "pie". Only about 80% of the pie is "pools" you can join.)
Single pool luck:
If you are in a pool that is 10% of the total pools = 10% lucky, 90% unlucky

Multi-pool luck:
If you are in a pools that total 50% of the pools = 50% lucky, 50% unlucky

All-pool luck:
If you are in a pools that total 100% of the pools = 100% lucky, 0% unlucky

Thus, losses in ONE pool, are 90% of "luck". Losses in half the pools is only about 50%. If you average over time, all your losses from a single pool, they will be greater than 20% of your potential income. (That includes down-time and lost shares and fees and withholding and orphaned and stale-blocks.) If you average out your losses from multi-pools, they will be less than 5% of your potential. Thus, joining only ONE more pool, will give you back the 3% that most pools charge. But it will not give you back all the bonuses that you may loose, from splitting into pools that do not actually offer the same rewards to start-off.

EG, some give name-coins (which is a nice 5% bonus). Some give you the "transaction fees" that are being paid to process the blocks. (Others that do not, are keeping those fees, in addition to the 3% they charge you to mine for them!) Some just "have poor operating and records", seemingly loosing your "shares", or mysteriously "restart", just as shares start to rise, and the pool-hop decay knocks share-values back down for the next block being found. Thus, leaving the majority of the next blocks funds going to the pool operator. Though, when audited, they "look" like they honestly paid all "due shares", even though they are manipulating what "due" values are.

In the end, it is the best way to "reduce losses". Thus, resulting in apparent gains. It is 100% better than solo-mining, guaranteed. It is at-least 50% better than pool-mining on the largest pool. So, win-win... rather... less-loss less-loss.

Isn't this rather affected by these profit-switching pools now, which can provide a lot more hash power than the ordinary pools and thus get all the coins when they're on a particular currency? See this thread regarding stablecoin for example https://bitcointalk.org/index.php?topic=349198.440

Note I discussed the following in my newbie thread here https://bitcointalk.org/index.php?topic=358711.msg3836730#msg3836730 as I had no idea how long it would be before I could post in other threads but now it's unlocked, I thought it might be better to discuss it here. If you'd rather reply in that thread though, please do.

I've been experimenting with load-balancing amongst three pools with my 464Kh/s but I've encountered some issues. The readme suggestst that using --balance it should share out the hashrate equally between all three pools I've specified but when I was testing earlier, stablecoin.miners.eu (160-270MH/s) showed 101 Kh/s, miningpool.co showed 240 Kh/s and coin-base.org (13-25MH/s) showed No Active Workers, hashrate or difficulty, despite the fact that cgminer was showing a list of accepted for that pool (pool 2) and no mention of pool 0 or 1. When I refreshed the site, I could see that my Accepted was increasing on there (although a lot of Accepteds in cgminer don't seem to translate into accepted on the site), so I guess there's just some issue with the site not being able to detect the worker/hashrate when using --balance, although it does still accept shares (although I can't tell if it's accepting all it should or if some are getting ignored wrongly).

When I tried --load-balance, with coin-base.org, miningpool.co and pnwminer.com (the first two are Prop, the last PPLNS) and without specifying any quotas, which the readme suggests should split it equally, it seemed to allocate most of it to pnwminer.com, around 350KH/s, with miningpool.co getting around 85 KH/s and coin-base.org the rest. I don't know if it would work better if I specified quotas but that seems hard to do properly when the pools' hashrates vary a lot throughout the day.