Topic: Multipool - the pool mining pool (with source code) - page 18. (Read 48293 times)

Aye, the pool was down . With all these users, the pool decided that the getwork response rates for the pool it was requesting work from wasn't fast enough, temporarily banned it, and switched to another pool. But the rates still weren't good enough, so it banned all the pools in succession. I've reset the ban counter and will figure out how to get work faster.

It is a third-level domain registrar, so some of the other subdomains might have been blacklisted.

That's right: the utility is my prediction for the expected utility of each share submitted. A single solo share has utility of 1, but utility of pool shares fluctuates widely. For the stats pages, utility is summed for each round, pool, and user. If your utility is greater than the number of shares, you are predicted to be doing better than solo mining. Efficiency is the ratio of the actual rewards allotted by the pools to the expected rewards of solo mining. In the long term, the ratio of the total utility to total shares should equal the total efficiency, assuming the prediction formulas are accurate.
There are slightly different formulas for different pools. Some you can figure out on your own, others are more clever.


That's .10 min, not .10 max. If you have 1.50 left, you get 1.50 out. The limit is there because there is no registration for the pool. You don't want someone making up a hundred thousand bitcoin accounts, submitting a hundred thousand shares (each worth 0.00005702 BTC), and costing the pool 50 BTC in fees to pay out 5.702 BTC in rewards.

1. The pool is down (went down 5 minutes ago)
2. If efficiency actuallty means efficiency it is not doing too well    0.864 over    3137 shares.

Hey Multipool

Just thought you might like to know that http://multipool.hpc.tw (including the user stats sub-d) is blocked by "Websense" at my work. None of the other bitcoin sites are. How the hell did you manage to piss them off? 

Utility seems to me more like an internal scoring method which pool is good to jump into than some "useful" value to caluculate with for people who don't know the inner algorithm.

I don't really understand the statistics

Shares   1455
Shares (pending)   3841
Utility   1927.513
Earned   0.08262282
Efficiency   0.996
Collected   0.00719988
Paid   0.00000000
Date   Sun Jun 19 14:07:13 2011

I submitted 1455 (confirmed) shares with a utility of 1927.513. Shouldn't my efficiency then be: 1927.513/1455 = 1.324 instead of 0.996?

There where connection issues the last 9 minutes. You just working on your pool?

BTW thank you for your pool. I really like it.

And one more.

Why limit payouts after a week of inactivity to .10 min.

If I quit your service and have only given .09 btc of service I've inadvertently gifted you 1.50+(more ATM) ....... WTF?

and I'm really not WTF'ing but if I was in that position, I'd be WTF'ing and more.......

EDIT:
changed .10 max to .10 min

I may have missed this, I apologize in advance if I did.

How are you computing the efficiency of improvement?

You are right - btcmine was the most difficult of the pools to scrape, because it does not indicate actual rewards on a per-round basis. The rounds are "earned" some time after they are "confirmed"! I've cleaned up the stats a bit (a couple of the rounds were mis-attributed), see if these are any better. However, there will always be rounds with very low or even zero rewards in score-based pools, because they have very high variability. Imagine: due to the exponential decay, all the shares that are worth 1.0 BTC now, will be worth only 0.00000615 BTC one hour from now - 12 decay periods later. And rounds can last for many hours...

Again, the score-based rewards result in higher variability. The expected utility is still above 100% for most rounds. However, since the expected utility of score-based pools levels out at about 90% during long rounds, they are usually the fallback option when all the other pools are also having long rounds (and shares-based expected utility keeps dropping to zero). If this happens too often, I might even have to add a solo pool option and generate my own getworks for the miners during dry periods! Being the go-to fallback option, score-based pools are usually not as profitable overall (but still more profitable than their operators would like you to think). It will take more time though to see whether the actual average rewards will match my utility predictions.

It is integral to maximize the number of pools in rotation. At many timepoints, even those with fees have higher expected utility than any other pool. If pools implement fair algorithms that make the expected utility constant throughout time, then fees will indeed play a greater role.

Because most of them are tiny and might rather get DOSed from a massive hopping pool like this I guess.

Also reducing variance is one of the reasons here, and this is best accomplished by having as many pools as possible. The pool hopping still gives you better results than average.

why not connect only to 0% fee pools? they are a lot of them

Here as well, I got 2 rounds at btcmine that are rewarded with 0 out of 5 rounds that are not pending any more - and interestingly they are in between rounds with payouts:
131504   Fri Jun 17 22:35:06 2011   145   179.681   0.00000000   0.000   0.00000000
131499   Fri Jun 17 22:01:12 2011   622   626.707   0.01991538   0.562   0.00000000
131469   Fri Jun 17 19:02:33 2011   93   108.445   0.00000000   0.000   0.00000000
Hope this helps in squashing bugs!

From what I see, in my account as well as on your demo account, slush pool and BTC Mine have very low efficiencies. Maybe this is due that they are using score based calculations? Either way, if it keeps up, I'd remove them for better eff. Other than that it works as advertised .

True, but in order to be a ddos target you have to be big. Because you're mining big pools, but don't need to be big yourself, you aren't a ddos target. Well, not for that reason anyway.

You retain the low variability advantage of the big pools, without the ddos disadvantage of being a big target. If you weren't pool hopping at all, you might not ever face being a target - unless your subscriber base got too big.

Regardless, until people start taking pool hopping seriously and start to target you, I'd expect you to have better uptime than any of the large pools.

BTW I gave the pool a spin, and got efficiency of 1.4 - so it works, all you doubters! And *sigh* yes, it works, all you who knew it would and fear the worst.

Multipool, a quick fyi - I notice that the results from btcmine were changing from 'pending' to being zeroed out, and then only 10 - 30 mins later showing the actual results. This was also affecting the page top stats for a while too. Screen scraping issue? Otherwise it was all simple and easy.

OK, funs over, back to eclipsemc (free plug for inaba's mine, you gotta try out the best mine with distributed servers that pool across AU, EU, and US - not separately!)


Evil bastidge, aintcha? 

First payouts are out!

Multipool has to wait until it collects the rewards from the pools. Since there are many pools with work split approximately evenly between them, it takes that much more time to cross the pools' automatic payout threshold. Although now, with more people, collections should speed up.

I'm making sure that screen scrapping is working adequately. Once I'm satisfied, I will include the confirmation-pending rounds as well. You do get paid for invalid rounds, as long as they've reached the head of the confirmed queue.

The server handles requests fine, but some of the pools are running pretty slow sometimes, and the work queue wasn't getting replenished fast enough, even with multiple request threads. Been tweaking this a bit, and have more ideas for improvements for later.

Actually, the equilibrium situation where all miners are perfectly rational (and the pools continue to use shares method) is quite different. It makes sense to jump at 43% point into a round only if everyone else continues to mine at the same rate. If you know everyone would jump at 43% point, you will have to jump earlier to maintain >100% efficiency, but then everyone else would jump earlier as well! In the 100% rational limit, no one would ever join a shares-based pool. Pool mining will become impossible and everyone will go back to solo mining again! In the real world, where only 5% of people are rational, I adjust accordingly.

All great ideas! If ip banning does get out of control, I can release a small proxy script for the miners to use to relay Multipool traffic. And if I do grow tired of being a pool tycoon and the mining pools still haven't implemented fair algorithms, I will release the source code, so that anyone can run their own metapool.

A pretty valid concern. If a person is in search of better uptime, they select the pool with the highest reliability. Multipool would at best only be as good as its own uptime. I would've just released the code outright, but there are already pool mining proxy programs available, and this is just too much fun.

He would create a loop... but why should he do that in the first place?!

What happens if you put your pool in the list of pools for your pool to pool in?

I've tried your pool with part of my computing power for about 24 hours now. Question: do you have an idea how long it takes before you start collecting anything? Cause I'm still at 0.000 collected right now. Thank you!

This would mean you donate 2.5% to BTCguild - why are shares then not immediately confirmed?

This was just a matter of time. Goodbye proportional-pools!