Small pool owners team up and reduce the variance

[skyhigh]

I wonder why all this small pools don't team up and create bigger 1000 Gh pools which would only help community and themselves. Some owner needs to script this up and start contacting all other small pool owners. Small pools come and go all the time. People try out small new pool but because they are so small they can't fight with the big boys. Takes them forever to solve a block, so most users give up and move to bigger pools even if there are fees involved. Big pools reduce the variance a lot.

It only takes 10 smaller pools to team up to become the 4th biggest bitcoin pool. More bigger pools would also make the bitcoin safer.

[1715050815]

1715050815

[1715050815]

1715050815

[1715050815]

1715050815

[gentakin]

Actually, smaller pools make bitcoins safer IMO.

[shads]

Coming very soon...

I've been building a pool aggregation server for the last few weeks.  Due the load I expect it to have to handle I've made a few mods to JSON-RPC api to enable more efficient transfer of work downstream.  With the performance of the standard bitcoind under high load there's a definate need to deal with this especially around block change time when work delivery rate needs to skyrocket for a few moments.

As a consequence also had to write a replacement for pushpool (although I expect pushpool could implement those changes pretty easily if the dev wants to).

So give me a few more days and I'll be releasing PoolServerJ along with Pool Aggregator...  PoolServerJ can be used as a drop in replacement for pushpool, not that there's anything wrong with pushpool but since I was building a straight java server for the aggregator it wasn't terribly difficult to make it capable of normal pool server action.

Since I'm making a premature announcement I'll mention a couple of features:

- Work caching for ultra fast delivery to clients
- Easy install on any OS, no compilation required, just a JDK installed
- Runs as a windows service
- Capable of pulling work from multiple sources (and tracking work to source)
- Run in pushpool compatibility mode for seamless changeover, only really needed for existing pushpool dependent pools that want to use Pool Aggregator.
- easy and graduated exit strategy for pools that grow large enough and want to go it alone.

 

[CubedRoot]

Just because a small pool takes longer to find a block doesnt mean you wont make as much as the larger pools.  Pool rewards are proportional (the majority anyways), so that means you get a portion of the rewards equal to the work you put in to the pool.  For example, on the larger pools, you might be doing .000001% of the work, so you will get .000001% of the rewards.
In a smaller pool that same rig might do as much as 10% of the work and get 10% of the rewards, although it would just take longer to get those said rewards when compared to a larger pool.   If you were to average out your daily returns for a 30 day window on a Large pool and a small pool, you would see that the amount of BTC you earned is pretty damn close to the same.
With one advantage----- Small pools usually have less problems. They dont get targetted for DDoS attacks, they usually have better valid share rates, and your rigs generally will run smoother due to not having any connectivity issues from jammed ISP pipes to the datacenter.

Now, shameless plug for our pool.  www.bithasher.com has only been running a few days now, were at 5 Ghash/sec and we found our fist block in 80 hours. Alot of the folks that took a chance by coming to us made some quick BTCs...and we were proud of that. So really, small pool are actually better than large pools if you dont mind waiting a few more days for your BTCs. Plus, small pools actually increase security of the Bitcoin network.

[shads]

Small pools feeding off a central aggregate pool can offer the same advantages with the added bonus of  reduced variance.  PoolServerJ includes failover functionality so if the larger aggregate happens to be DDoS'd the small pool will keep ticking over using work from it's own local bitcoin daemon.  Although DDos is a reduced risk for the aggregate pool due to the limited number of members and their relative level of bitcoin tech sophistication.  Protection strategies are much simpler with a small number of expected clients who are easy to identify and verify.

[Luke-Jr]

"Pool aggregation" is just making the pools a proxy to another pool (the "aggregator"). If you think it through, it makes little sense.

[CubedRoot]

Pool aggregation is ridiculuous to me. You can do the same type of pool failover in your mining scripts. There no need to involve another outside source for this... and possible pay a fee to the pool aggregator plus the pool(s) you mine in.  Its an absolute waste of time.
If you want redundancy, use one of the many free and  opensource miners, or miner starting scripts available and let your rig handle failover.

[shads]

If as a miner or a pool operator you're happy with high variance then I agree pool aggregation has no advantage.  But if it does matter to you then it's a key advantage.  Enabling small startup pools to offer low variance will help the pool market become more competitive.  If a new pool with some new feature starts up right now they have a huge disadvantage even they are offering a better product that the big 3.  The main reason miners join pools is to reduce variance and startups can't offer that.  As for doubling up on fees, it's a wholesale service and if fees were set at anything other than wholesale rates the aggregator would fall flat on their face.  If the pools feeding of the aggregator can't be competitive then no pools will join the aggregate pool.  When I do get to making a proper release announcement you'll see that those issues have all been fully addresses.

[skyhigh]

If as a miner or a pool operator you're happy with high variance then I agree pool aggregation has no advantage.  But if it does matter to you then it's a key advantage.  Enabling small startup pools to offer low variance will help the pool market become more competitive.  If a new pool with some new feature starts up right now they have a huge disadvantage even they are offering a better product that the big 3.  The main reason miners join pools is to reduce variance and startups can't offer that.  As for doubling up on fees, it's a wholesale service and if fees were set at anything other than wholesale rates the aggregator would fall flat on their face.  If the pools feeding of the aggregator can't be competitive then no pools will join the aggregate pool.  When I do get to making a proper release announcement you'll see that those issues have all been fully addresses.

Exactly. I don't understand how you guys don't see this as a huge advantage. All this smaller pools could join a mother pool to reduce a variance. They could still get new users on their own, everything would stay the same and if they ever grow enough to be able to make it on their own.

We could have 5 to 10 bigger pools in a matter of months, each pool with only 20% max market share. All those threads about deepbit getting too big or double spending or hack or whatever could go away. Most bigger miners tend to join big pools to minimize variance. Now that bitcoin is getting more and more exposure and new miners every day, top pools grow faster and the small ones has no chance to ever make it and owners just shuts it down after a while.

[CubedRoot]

Its useless for me, since I dont want to pay fees, or "royalties" to yet another middle party just  to reduce my variance. Im mining for the long haul, and if you average out your rewards over a month, the variance also averages to be about the same. So, in a months timeframe something like this is useless.

[Jack of Diamonds]

Just because a small pool takes longer to find a block doesnt mean you wont make as much as the larger pools.  Pool rewards are proportional (the majority anyways), so that means you get a portion of the rewards equal to the work you put in to the pool.

Not really true. Since pool luck only evens out in the long term (after weeks, months, years), you might incur massive losses by choosing to mine at a small startup pool right now.
I made this mistake a few weeks back, joined a pool in which I generated about 360k shares. It turns out the round got into 3+ million shares and nearly everybody ran off.

There are only a few cpu miners left, and if the block is ever found my prop. earning is about 30% of what I'd have earned at a site like deepbit or BTCGuild.

Since there is no 'long term' for those pools (it will die after the first block is found & bonuses harvested) it's a ridiculous gamble. It doesn't pay off anymore.

Of course, I'm naive so I joined yet another pool about 2 weeks ago, btcpool24.com. Turns out the block is prob. never going to be found now that the pool owner removed all bounties & major miners escaped. Another 50k shares wasted.

[Graet]

well ozco.in started a month ago, made it up to 85Ghash/s and has stabilized there - obviously still wanting to grow and welcoming new members every day
Est. Time To Find Block   22 Hours 26 Minutes
and we have found 1 /day for the last 3 days - our variance is evening out
I wouldnt see an advantage now to "joining other pools" to aggregate. Though with the large number of new pools starting every day it is certainly getting harder for new pools to get a foothold.
From some graphs i have been watching the network hashrate has fallen  a little - making operating pools even more competitive.

While "opening a pool" appears easy it take a lot of work and dedication to be succesful, thankfully ozco.in has had some awseome members step up and help hugely with codeing, testing and resolving bugs and i have been able to spend 14-18 hours a day supporting members (something not all pool owners are able to do).

I say to ppl considering mining "do your research - make sure its viable for you" before you spend money
I say to ppl considering joining a pool "do your research - make sure its the right pool for you" (even about my own pool) before you join a pool

I say to ppl considering opening pools "do your research - make sure you have the right strategy to draw miners, have functional software (most pool software needs a *lot* of work before it works well/efficiently), I have set my pools fee at 1% due to australian hosting fees being comparitively expensive - at this rate ozco.in need 200Ghahs/s to be paying its own way. My mining has subsidised the pool.-  A lot to consider before starting up.

[skyhigh]

Graet, you only focusing on the very short term here. You recognized that there are new pools popping up almost daily and that some owners might not know what they are up against.  Now picture everything 6 to 12 months down the road. There could be 100s of small pools and only a handful of decent size pools. Many new comers will start directly with a larger pool, just because most are there so it must be a good thing. While the few that will test smaller pools will be up against the huge variance and might in the end give up with small pools and also join big ones.

Example of the pool you mentioned. Even if you guys will grow for the next 6 months, chances that you will outgrow your competition and the flood of new possible pools are very thin. In 6 months time even if you will be at 300 Gh you won't be able to solve a block in a day, might take you 3 or 10 days. Picture the variance your pool will have. While if it would be in the mother pool for lets say extra 0.5% fee, you guys would have 10-20% of the overall hashrate and almost no variance.

Whoever thinks that variance will even out down the road, in a period of lets say 12 months, needs to understand at what lightning speed the whole network grows and the number of pools we will have in a very short time. Soon there will be 100s of pools and each new one will have small chance of ever making it on their own. If they would be a part of a mother pool, each and single one could survive and get their share of the pie, while their users would have minimal variance.