Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC

[frankiebits]

I just made some edits , everyone no matter their individual hash rate gets the same payout. This is why minimum hash rate to join is very important.

A pool which guaranteed the exact same payout to all members, regardless of hash rate, will attract members with the lowest possible hash rate and deter potential members with higher hash rates. Say you're the operator of this hypothetical pool, and you set a minimum hash rate of 300 MHash/s - that keeps out miners with anything slower than one 5870, but equally someone with one or more 5970s will prefer to use a different pool - what's the point in using your pool if they're guaranteed to get paid the same as a miner using only a 5870? Might as well use a different pool and get paid more.

Your proposal would work, but it would have the side-effect of limiting pool membership to owners of one particular GPU. Personally, I'd prefer to belong to a big pool (i.e. one that doesn't limit membership) as the payouts will be more frequent.

Ok over 200mhash/s may be too high for now.

I just feel like there has to be a better way to run a pool. What about 10 tiers , starting at 50mhash up to 500mhash in increments of 50 so you would attract the larger range of users. The tiers each having higher payouts as you go up so not to turn off the more powerful users, but each whichever tier you are in you will get the same as everyone else in that tier. Maybe I am getting ahead of myself considering I am new here but I think if a few people put their heads together we could come up with something more attractive and efficient than the current pool models. The eventual goal will not be to have the largest pool, but the most powerful pool with a smaller amount of members.

If anyone would like to actually work on creating a completely new model for a pool , whether you like my ideas or not , ,let me know, it is worth a shot.

[1714002839]

1714002839

[1714002839]

1714002839

[1714002839]

1714002839

[Grinder]

What you are describing is a socialist pool. Good luck with that here.

[Thndr]

That's still limiting membership, and those at the lowest level of a tier might get more than the unlimited pools, but those towards and right below the next tiers would get less and have no reason for joining the pool. So the only people who would benefit would be those closest to the minimal hashrate for that tier

The only way to resolve that is to make more tiers, and more tiers, until: You have a pool that pays based on how fast they go on a sliding scale. Then you have to worry about how much they mine. You don't want a person mining for 1 minute to get paid the same as someone who mined for 2 hours. So you scale based on how much work has been done, or shares. Since the hashrate determines how much work is done, it's an accurate way to measure participation and reward everyone equally.

And then you end up with a pool like everyone else.

Making a pool limited by hashrate essentially gives the same rewards as other pool, only for the fact that unless you got enough speed in those few amount of people to make 130Ghash, they're better off joining Slush's pool, or BitcoinPool. A slower pool, faster miners would get more shares. A faster pool, the faster miner gets less shares per block, but gets more blocks. A pool could get 1 block a day, and the miner gets 1BTC per block, or a pool could get 10 blocks a day, and the miner gets 0.1BTC per block. At the end of the day, they still have 1BTC.



A more beneficial idea would be limiting the daily amount of users, and using a ultra-mining computer to almost guarantee 1 block per hour, and distrobute 50% of that to all the daily miners, and the other 50% based on share. As long as you don't run the ultra-miner too long and only if there hasn't been a block generated in that hour, it shouldn't affect the difficulty too much.

[slush]

I think if a few people put their heads together we could come up with something more attractive and efficient than the current pool models.

What kind of 'effectivity' are you talking about? Why it should be more "effective" to join my CPU miner to pool full of CPU miners? Or 5970 to pool full of 5970? It would be great if you can do the math showing improvement in pool clusters like this...

If anyone would like to actually work on creating a completely new model for a pool

I probably don't see the improvement in your model.

[frankiebits]

I think if a few people put their heads together we could come up with something more attractive and efficient than the current pool models.

What kind of 'effectivity' are you talking about? Why it should be more "effective" to join my CPU miner to pool full of CPU miners? Or 5970 to pool full of 5970? It would be great if you can do the math showing improvement in pool clusters like this...

If anyone would like to actually work on creating a completely new model for a pool

I probably don't see the improvement in your model.

You saying a pool of 1000 5970's is not more effective than 1000 CPU miners?

All these pools cater to the low end user a.k.a CPU miner, I am imagining a pool that would cater to the higher end user.

[slush]

You saying a pool of 1000 5970's is not more effective than 1000 CPU miners?

From side of the miners? Yes. There is no reason to ban CPU users and build "GPU clusters".

There is only one exception; 1000 GPU users will make less pool load per ghash than CPU users. But this does not cut miner's income, it is just the problem of the pool operator.

To explain it better. There are two variables in the game - miner's hashrate and pool hashrate.

a) Miner hashrate affect his income. Less individual hashrate - less payouts.
b) Pool hashrate affect the frequency of payouts. Less pool hashrate - less steady payouts.

There is nothing more behind that. Pool hashrate, type of miners in the pool or anything else does NOT affect miner's income. So I don't see any reason for making "GPU only" clusters. Only potential reason might be the pool (server) load, but it can be done by another solutions than by banning  CPU users.

[jgarzik]

There is nothing more behind that. Pool hashrate, type of miners in the pool or anything else does NOT affect miner's income. So I don't see any reason for making "GPU only" clusters. Only potential reason might be the pool (server) load, but it can be done by another solutions than by banning  CPU users.

One option is simply to raise the difficulty.

I've been thinking about increasing the difficult by 16 bits, in one of my pool server projects.

[frankiebits]

You saying a pool of 1000 5970's is not more effective than 1000 CPU miners?

From side of the miners? Yes. There is no reason to ban CPU users and build "GPU clusters".

There is only one exception; 1000 GPU users will make less pool load per ghash than CPU users. But this does not cut miner's income, it is just the problem of the pool operator.

To explain it better. There are two variables in the game - miner's hashrate and pool hashrate.

a) Miner hashrate affect his income. Less individual hashrate - less payouts.
b) Pool hashrate affect the frequency of payouts. Less pool hashrate - less steady payouts.

There is nothing more behind that. Pool hashrate, type of miners in the pool or anything else does NOT affect miner's income. So I don't see any reason for making "GPU only" clusters. Only potential reason might be the pool (server) load, but it can be done by another solutions than by banning  CPU users.

The amount of miners doesn't effect payout? That does not make any sense. Wouldn't the of the #ofminers to poolhashrate have an effect on the payouts?

Edit: I see how it doesn't , with the current way the pools are run.

[frankiebits]

I am going to take a walk and think.... been on this PC too much today..