Bitcoin Forum

Bitcoin => Mining => Topic started by: frankiebits on March 18, 2011, 12:39:24 PM



Title: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 18, 2011, 12:39:24 PM
PLEASE VOTE!


I have been reading and playing around with bitcoin software for a couple of weeks now. I certainly do not consider myself an expert. Most decisions I had made have came to me very easily and I feel I am understanding the network more and more everyday.

At first I decided I do not want to pool, even though I am hashing rather slowly right now I will be increasing the speed as much and as often as I can.
I know if I pool I will see fractions of bitcoins coming in at a more steady rate than if I mine solo which with my current rig right now will take me over a month of mining to see a bitcoin.

My questions about pooling are...

Was the network designed for pooling?

Would it be more beneficial to miners if there were no pools?

Doesn't having pools hashing at mega rates hurt the chances of the new comers or slow hash solo miners that are integral to the growth of the network?

I am trying to look at it from outside the box not really as a miner.

I want to know the effect mining pooling will have on the network , the difficulty , inflation , deflation, motivation of new miners and so forth and if in the long term if it will hurt the network?

Anything else interesting you might want to add go ahead I'm all ears.

PLEASE VOTE!


Title: Re: Too pool or not to pool? That is the question...
Post by: CCCMikey on March 18, 2011, 12:48:55 PM
In my mind it's a simple calculation. The more miners there are, the less each miner will find. That's how the system is made. It will reach a point where only the most efficient systems will be able to mine coins at a rate approaching equal to their cost in electricity; balanced by the value of individual coins relative to the currency of the power bill.

Mining will give you a chance at a windfall, or nothing at all. Joining a pool increases your chance of a smaller amount, but over a long period of time it should be equal I think - unless the mining equipment is overcoming the power cost by offsetting it to someone else.

That's my thoughts anyway, but I don't know much about pooling.


Title: Re: Too pool or not to pool? That is the question...
Post by: snedie on March 18, 2011, 12:49:02 PM
Pooling is good for slower miners, and provides a location for combining hashing power. This location will give these slower miners a slightly higher payout then if they went solo.

However, for faster miners (5970 and upwards) solo mining is a good option, but payouts can be very irregular. There is an "In between" for GPU miners however, and smaller pools of fast miners are an excellent way to increase regularity of payments whilst maintaining high payouts. http://btcmine.com (http://btcmine.com) is a good example of one such pool.


Title: Re: Too pool or not to pool? That is the question...
Post by: nster on March 18, 2011, 01:31:04 PM
I don't understand HOW a pool could hurt mining, all it does is help!

Pools are just a bunch of miners working together to have smaller rewards more frequently, it helps the lower hashrate miners and gives security to the higher hashrate ones. They do not "steal" any btc from the smaller miners, as the hashrate of the pool is the SUM of the miners inside them


Title: Re: Too pool or not to pool? That is the question...
Post by: frankiebits on March 18, 2011, 01:41:27 PM
I don't understand HOW a pool could hurt mining, all it does is help!

Pools are just a bunch of miners working together to have smaller rewards more frequently, it helps the lower hashrate miners and gives security to the higher hashrate ones. They do not "steal" any btc from the smaller miners, as the hashrate of the pool is the SUM of the miners inside them

On the network a pool is recognized as a single miner? Then the pools software handles the distribution of BTC? Is this correct?

I never said anything about anyone stealing either....


Title: Re: Too pool or not to pool? That is the question...
Post by: snedie on March 18, 2011, 01:51:00 PM
I don't understand HOW a pool could hurt mining, all it does is help!

Pools are just a bunch of miners working together to have smaller rewards more frequently, it helps the lower hashrate miners and gives security to the higher hashrate ones. They do not "steal" any btc from the smaller miners, as the hashrate of the pool is the SUM of the miners inside them

On the network a pool is recognized as a single miner? Then the pools software handles the distribution of BTC? Is this correct?

I never said anything about anyone stealing either....

Exactly correct. The pool submits the solved blocks to the network, and receives the BTC. This is then distributed to miners according to their shares. Each pool does this a little differently, but the biggest difference to the amount received per share is the amount of users in the pool: The more users, the less you get for each share but the faster blocks are solved.


Title: Re: Too pool or not to pool? That is the question...
Post by: frankiebits on March 18, 2011, 01:59:09 PM
I don't understand HOW a pool could hurt mining, all it does is help!

Pools are just a bunch of miners working together to have smaller rewards more frequently, it helps the lower hashrate miners and gives security to the higher hashrate ones. They do not "steal" any btc from the smaller miners, as the hashrate of the pool is the SUM of the miners inside them

On the network a pool is recognized as a single miner? Then the pools software handles the distribution of BTC? Is this correct?

I never said anything about anyone stealing either....

Exactly correct. The pool submits the solved blocks to the network, and receives the BTC. This is then distributed to miners according to their shares. Each pool does this a little differently, but the biggest difference to the amount received per share is the amount of users in the pool: The more users, the less you get for each share but the faster blocks are solved.

So as more and more people join pools the number of miners drops significantly, how does the number of total miners effect the network if at all?


Title: Re: Too pool or not to pool? That is the question...
Post by: Littleshop on March 18, 2011, 02:08:51 PM
I don't understand HOW a pool could hurt mining, all it does is help!

Pools are just a bunch of miners working together to have smaller rewards more frequently, it helps the lower hashrate miners and gives security to the higher hashrate ones. They do not "steal" any btc from the smaller miners, as the hashrate of the pool is the SUM of the miners inside them

Pooling does not hurt mining but it can (not saying it does) hurt both the stability of bitcoin and the security of bitcoin.

If two large pools covered more then 50% of mining they owners could collude together to change transactions.  This is unlikely but it is not nearly as unlikely as 51% of individual miners coordinating and doing the same thing. 

Secondly if a pool fails it takes down a much greater amount of computing power for the network then if a single miner or even a group of miners fail.  It removes a part of the redundancy of the bitcoin network. 

That being said, I do group mine with two different pools and I solo mine as well and thank the pool operators for making pools. Pooling is not nearly as lucrative for the pool operator as I thought, as with a 2% commission a pool operator with 25% of all of the mining still does not make over 50BTC a day.  Someone could get a similar amount with about five 5970's.   

So the answer is, I pool.  :)


Title: Re: Too pool or not to pool? That is the question...
Post by: frankiebits on March 18, 2011, 02:38:29 PM
I don't understand HOW a pool could hurt mining, all it does is help!

Pools are just a bunch of miners working together to have smaller rewards more frequently, it helps the lower hashrate miners and gives security to the higher hashrate ones. They do not "steal" any btc from the smaller miners, as the hashrate of the pool is the SUM of the miners inside them

Pooling does not hurt mining but it can (not saying it does) hurt both the stability of bitcoin and the security of bitcoin.

If two large pools covered more then 50% of mining they owners could collude together to change transactions.  This is unlikely but it is not nearly as unlikely as 51% of individual miners coordinating and doing the same thing.  

Secondly if a pool fails it takes down a much greater amount of computing power for the network then if a single miner or even a group of miners fail.  It removes a part of the redundancy of the bitcoin network.  


This is what I am trying to understand, if you are in it for the long haul these things should be very important to you. I'm sure my poll will be proof that the majority of miners are in pools. If pools start pooling there will be a serious problem right? Like you said just they just need 51% , all you need if a few very large powerful pools to join together. This may not happen now or not for ten years but this a very serious possibility correct?  

Is there anyway to see the number of miners, their power , and how much blocks they are solving?

Edit: Also what is stopping one person with a nice chunk of cash from taking majority control of the network right now?

Wherever there is money, there is greed and corruption, the whole point of this currency is to be more secure than others so I am just trying to understand how exactly this security is accomplished. Like you said pools can possibly be a threat to this security... this is why I am trying to understand how pools effect the network as a whole and how it operates.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: snedie on March 18, 2011, 04:19:42 PM
As the overall hashing rate of the network goes up, so does the difficulty. Now for the new "Super user" they will still earn a decent amount, but for smaller users it become unprofitable. This difficulty factor prevents inflation beyond a desired amount, and it varies to maintain the overall value of a bitcoin.

However, your talking about £100k's, if not in excess of £1m, of equipment costs to reach even 50% of the bitcoin network hashing potential.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 18, 2011, 07:52:55 PM
As the overall hashing rate of the network goes up, so does the difficulty. Now for the new "Super user" they will still earn a decent amount, but for smaller users it become unprofitable. This difficulty factor prevents inflation beyond a desired amount, and it varies to maintain the overall value of a bitcoin.

However, your talking about £100k's, if not in excess of £1m, of equipment costs to reach even 50% of the bitcoin network hashing potential.

Does overall hashing rate simply increase by the combined efforts of the entire network or are there other factors such as total amount of miners or the average hashing rate to number of miners?

My question basically is does total number of "miners" (a pool representing 1 miner) on the network also have any influence on the rate at which the difficulty rises\falls?



Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: snedie on March 18, 2011, 08:16:52 PM
As the overall hashing rate of the network goes up, so does the difficulty. Now for the new "Super user" they will still earn a decent amount, but for smaller users it become unprofitable. This difficulty factor prevents inflation beyond a desired amount, and it varies to maintain the overall value of a bitcoin.

However, your talking about £100k's, if not in excess of £1m, of equipment costs to reach even 50% of the bitcoin network hashing potential.

Does overall hashing rate simply increase by the combined efforts of the entire network or are there other factors such as total amount of miners or the average hashing rate to number of miners?

My question basically is does total number of "miners" (a pool representing 1 miner) on the network also have any influence on the rate at which the difficulty rises\falls?



In simple form no, but it really depends on what each miner is bringing to the network. You could lose 2000 CPU miners and the difficulty would barely change, but loosing even 50 GPU miners would be a large enough event to shift the difficulty. This also applies if a pool as large as "Slush" ever went down for a prolonged period in time as 120Ghash/s would instantly be lost.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: Ricochet on March 18, 2011, 08:52:27 PM
Except that the early adopters here are more likely to be highly attentive of what's happening with their clients, and if Slush's pool were to suddenly go down for more than a day or two, I suspect the networking power would return in the form of the growth of other pools fairly quickly.  A temporary loss of 120 Ghash/s yes, but not for a very long time before people manually switch to another solution.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: martok on March 18, 2011, 09:09:52 PM
I have done both and am currently pooling. However, I am considering moving away from pools.
First, you need to trust the pool operator. I am not saying they are not honest folks but there is no way an outsider to the pool can verify that the operator is only taking what he says he is taking.
Second, these pools are mostly being run by one person and lack things like fault tolerance. If Joe pool operator makes a code change that breaks things, the pool goes down. He isn't likely to have a development environment, test deployments etc. So wwe have 2-3% comissions then there is the downtime which reduces efficiency even further.
So in that respect, I am thinking solo provides the greatest efficiency. There is no overhead loss due to comissions or pool outages.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: jgarzik on March 18, 2011, 09:14:43 PM
First, you need to trust the pool operator. I am not saying they are not honest folks but there is no way an outsider to the pool can verify that the operator is only taking what he says he is taking.

Well, you can see precisely where the 50 BTC from each block goes, at http://blockexplorer.com/



Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 18, 2011, 09:21:38 PM
As the overall hashing rate of the network goes up, so does the difficulty. Now for the new "Super user" they will still earn a decent amount, but for smaller users it become unprofitable. This difficulty factor prevents inflation beyond a desired amount, and it varies to maintain the overall value of a bitcoin.

However, your talking about £100k's, if not in excess of £1m, of equipment costs to reach even 50% of the bitcoin network hashing potential.

Does overall hashing rate simply increase by the combined efforts of the entire network or are there other factors such as total amount of miners or the average hashing rate to number of miners?

My question basically is does total number of "miners" (a pool representing 1 miner) on the network also have any influence on the rate at which the difficulty rises\falls?



In simple form no, but it really depends on what each miner is bringing to the network. You could lose 2000 CPU miners and the difficulty would barely change, but loosing even 50 GPU miners would be a large enough event to shift the difficulty. This also applies if a pool as large as "Slush" ever went down for a prolonged period in time as 120Ghash/s would instantly be lost.

Say everyone in every pool started solo mining, would that also have an effect on the difficulty?


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: martok on March 18, 2011, 09:32:15 PM
First, you need to trust the pool operator. I am not saying they are not honest folks but there is no way an outsider to the pool can verify that the operator is only taking what he says he is taking.

Well, you can see precisely where the 50 BTC from each block goes, at http://blockexplorer.com/



But what does that tell you? Let's say I ran a pool with a 5% comission. So I get 2.5 BTC from each block. What stops me from having my pool software simulate a few 5970 clients, awarding me their score in the pool rankings. That of course would be done with seperate addresses so it wouldn't show up on block explorer. I can't think of a way to protect against something like that.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: dust on March 18, 2011, 09:35:59 PM
First, you need to trust the pool operator. I am not saying they are not honest folks but there is no way an outsider to the pool can verify that the operator is only taking what he says he is taking.

Well, you can see precisely where the 50 BTC from each block goes, at http://blockexplorer.com/



But what does that tell you? Let's say I ran a pool with a 5% comission. So I get 2.5 BTC from each block. What stops me from having my pool software simulate a few 5970 clients, awarding me their score in the pool rankings. That of course would be done with seperate addresses so it wouldn't show up on block explorer. I can't think of a way to protect against something like that.

Over time, participants could get together and realize that their combined returns were less than expected.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 18, 2011, 10:38:44 PM
But what does that tell you? Let's say I ran a pool with a 5% comission. So I get 2.5 BTC from each block. What stops me from having my pool software simulate a few 5970 clients, awarding me their score in the pool rankings. That of course would be done with seperate addresses so it wouldn't show up on block explorer. I can't think of a way to protect against something like that.
It's enough just to compare your expected payout to real one. It should be the same on average, every participant can do this.

Second, these pools are mostly being run by one person and lack things like fault tolerance. If Joe pool operator makes a code change that breaks things, the pool goes down. He isn't likely to have a development environment, test deployments etc. So wwe have 2-3% comissions then there is the downtime which reduces efficiency even further.
So in that respect, I am thinking solo provides the greatest efficiency. There is no overhead loss due to comissions or pool outages.
Do you have any statistics on pool outages or proofs of fault tolerance lack ? How would you know if pool operators have test deployments or not ?
Please, don't make such assumptions.

Solo mining efficiency is higher only if you have hashing speed high enough to find blocks faster than difficulty adjustment steps.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: snedie on March 18, 2011, 10:41:54 PM
As the overall hashing rate of the network goes up, so does the difficulty. Now for the new "Super user" they will still earn a decent amount, but for smaller users it become unprofitable. This difficulty factor prevents inflation beyond a desired amount, and it varies to maintain the overall value of a bitcoin.

However, your talking about £100k's, if not in excess of £1m, of equipment costs to reach even 50% of the bitcoin network hashing potential.

Does overall hashing rate simply increase by the combined efforts of the entire network or are there other factors such as total amount of miners or the average hashing rate to number of miners?

My question basically is does total number of "miners" (a pool representing 1 miner) on the network also have any influence on the rate at which the difficulty rises\falls?



In simple form no, but it really depends on what each miner is bringing to the network. You could lose 2000 CPU miners and the difficulty would barely change, but loosing even 50 GPU miners would be a large enough event to shift the difficulty. This also applies if a pool as large as "Slush" ever went down for a prolonged period in time as 120Ghash/s would instantly be lost.

Say everyone in every pool started solo mining, would that also have an effect on the difficulty?

Nothing, the hashing rate for the entire network would remain the same, but the GPU miners would probably solve a much larger percentage of the blocks: Basically all it's going to affect is the amount of money that CPU miners don't already get.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 18, 2011, 11:09:43 PM
Thanks to everyone for answering questions!

So is there a pool that requires each member to have a minimum hash/s to join?

I would assume the pool that has the highest hashrate/member ratio will be the ones making the most BTC.
I would be interested in joining or maybe creating such a pool.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: snedie on March 18, 2011, 11:17:30 PM
Thanks to everyone for answering questions!

So is there a pool that requires each member to have a minimum hash/s to join?

I would assume the pool that has the highest hashrate/member ratio will be the ones making the most BTC.
I would be interested in joining or maybe creating such a pool.

The smaller the pool the higher your payout. Currently I am in this pool http://btcmine.com (http://btcmine.com) but it isn't generating payouts for days at a time so I will be leaving. The bitpenny pool seems to be much more advantageous to me however as it pays out even if a block isn't solved: This puts the "Gamble" onto the owner of the pool instead, and for this reason he takes 10% commission.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 18, 2011, 11:25:06 PM
Thanks to everyone for answering questions!

So is there a pool that requires each member to have a minimum hash/s to join?

I would assume the pool that has the highest hashrate/member ratio will be the ones making the most BTC.
I would be interested in joining or maybe creating such a pool.

The smaller the pool the higher your payout. Currently I am in this pool http://btcmine.com (http://btcmine.com) but it isn't generating payouts for days at a time so I will be leaving. The bitpenny pool seems to be much more advantageous to me however as it pays out even if a block isn't solved: This puts the "Gamble" onto the owner of the pool instead, and for this reason he takes 10% commission.

Thanks, so I guess the idea of having a pool where members must meet a certain hash rate sayyy 100mhash/s for example does not exist yet?


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 18, 2011, 11:27:15 PM
Thanks, so I guess the idea of having a pool where members must meet a certain hash rate sayyy 100mhash/s for example does not exist yet?
Why would someone do that ?
This restriction will only be necessary for some small-scale pool which is incapable to serve many slow miners.
Pool without restrictions gets more users and makes more BTC.

The smaller the pool the higher your payout. Currently I am in this pool http://btcmine.com (http://btcmine.com) but it isn't generating payouts for days at a time so I will be leaving. The bitpenny pool seems to be much more advantageous to me however as it pays out even if a block isn't solved: This puts the "Gamble" onto the owner of the pool instead, and for this reason he takes 10% commission.
The smaller the pool the higher your payout per block. But bigger pools have more blocks, so overall payment is the same.
Bitpenny is not the only one with pay-per-share payout. My pool (http://deepbit.net) provides it too.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: slush on March 18, 2011, 11:35:07 PM
If Joe pool operator makes a code change that breaks things, the pool goes down. He isn't likely to have a development environment, test deployments etc. So wwe have 2-3% comissions then there is the downtime which reduces efficiency even further.

Teoretically - yes. Practically - I'm doing tests for more than 50% of time spent on the development. I'm sure that pool operator(s) of other big pool(s) does the similar. In fact, my pool started up 16.12.2010 and except two server restarts in January and slightly lower hashrate (drop around 30%) during 2hours of DoS attack in February, it is up all the time.

And yes, I have development environment and even stage environment on other machines in the same data center.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: snedie on March 18, 2011, 11:45:48 PM
Thanks, so I guess the idea of having a pool where members must meet a certain hash rate sayyy 100mhash/s for example does not exist yet?
Why would someone do that ?
This restriction will only be necessary for some small-scale pool which is incapable to serve many slow miners.
Pool without restrictions gets more users and makes more BTC.

The smaller the pool the higher your payout. Currently I am in this pool http://btcmine.com (http://btcmine.com) but it isn't generating payouts for days at a time so I will be leaving. The bitpenny pool seems to be much more advantageous to me however as it pays out even if a block isn't solved: This puts the "Gamble" onto the owner of the pool instead, and for this reason he takes 10% commission.
The smaller the pool the higher your payout per block. But bigger pools have more blocks, so overall payment is the same.
Bitpenny is not the only one with pay-per-share payout. My pool (http://deepbit.net) provides it too.

3% fee, you got me within the next 12 hours in your pool  8)

You got any estimates for pay-per-share at 1.1Ghash/s (And at 1.3Ghash/s if you can too please).


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 18, 2011, 11:57:30 PM
You got any estimates for pay-per-share at 1.1Ghash/s (And at 1.3Ghash/s if you can too please).
1.1 GH/s will give you 13 BTC per day at pay-per-share or 14 BTC per day with proportional payout


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: Thndr on March 19, 2011, 12:25:08 AM
You got any estimates for pay-per-share at 1.1Ghash/s (And at 1.3Ghash/s if you can too please).
1.1 GH/s will give you 13 BTC per day at pay-per-share or 14 BTC per day with proportional payout
So that's almost 1BTC/day at 70MH/s, right?

----

As long as we're discussing different kind of pools:


What if someone created a pool with a limited max hashrate dedicated to just CPU miners?

What if someone created a pool that combined a lottery system along with participation? (24 random users get a guaranteed 1BTC per block, and the remaining 25BTC is divided among the entire pool)

What if someone created a small pool that had a limited amount of users and every hour, runs a non-paid 400GH/s client for 1 minute (unless it finds a block in less than a minute)? The users could be limited to a rotating list of 25 users per day. *2BTC per hour, about 45BTC per day*


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 02:12:17 AM
Thanks, so I guess the idea of having a pool where members must meet a certain hash rate sayyy 100mhash/s for example does not exist yet?
Why would someone do that ?
This restriction will only be necessary for some small-scale pool which is incapable to serve many slow miners.
Pool without restrictions gets more users and makes more BTC.

Say you have a pool with 100 members with the exact same hash rate as a pool with 1000 members, wouldn't the smaller pool generate the same amount of bitcoin and each member would get 10x more than in the larger pool?


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 19, 2011, 06:22:08 AM
Thanks, so I guess the idea of having a pool where members must meet a certain hash rate sayyy 100mhash/s for example does not exist yet?
Why would someone do that ?
This restriction will only be necessary for some small-scale pool which is incapable to serve many slow miners.
Pool without restrictions gets more users and makes more BTC.
Say you have a pool with 100 members with the exact same hash rate as a pool with 1000 members, wouldn't the smaller pool generate the same amount of bitcoin and each member would get 10x more than in the larger pool?
Yes, but each user will receive same reward in both pools. If a user with high hashing rate will go from one pool to another, his payout will be exactly the same. Same goes for "slow" user.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 19, 2011, 06:26:56 AM
As long as we're discussing different kind of pools:

What if someone created a pool with a limited max hashrate dedicated to just CPU miners?
It will only be interesting for users that don't understand how mining works.

Let's say that 1000 CPU users make a pool, then their hash rate will be only 1-10 MH/s total and it will create blocks much slower than other pools.
There are no any advantages for CPU users in such pool.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: os008 on March 19, 2011, 11:56:32 AM
PLEASE VOTE!
...
PLEASE VOTE!
LOL; it's voting day today here in Egypt on the constitution changes. Everyone is saying "please vote", even on TV. It's funny seeing it here too :D.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 03:33:49 PM
Thanks, so I guess the idea of having a pool where members must meet a certain hash rate sayyy 100mhash/s for example does not exist yet?
Why would someone do that ?
This restriction will only be necessary for some small-scale pool which is incapable to serve many slow miners.
Pool without restrictions gets more users and makes more BTC.
Say you have a pool with 100 members with the exact same hash rate as a pool with 1000 members, wouldn't the smaller pool generate the same amount of bitcoin and each member would get 10x more than in the larger pool?
Yes, but each user will receive same reward in both pools. If a user with high hashing rate will go from one pool to another, his payout will be exactly the same. Same goes for "slow" user.

If the pool was "pay per share" I agree with you. If it was not in theory a pool with 100 members with a 50 ghash/s rate compared to a pool with 1000 members with the same rate the first pool should pay out more because they are solving the same amount of blocks and have to pay it out to lesser amount of people therefore each person would get more BTC. Just like if I two people were mining solo and one has 10x the hash rate he should in theory get 10x as much because 1 pool = 1 miner.


Oh and if anyone if interested I decided to test out pooling on BITPENNY for around 12hours @ 80 mhash/s and got 0.5 btc  for around 850 shares. So you can do some math and figure out what you would get back with your hash rate on that pool. Hope it helps , if it does DONATE ME SOME BTC  ;)   


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 03:44:03 PM
PLEASE VOTE!
...
PLEASE VOTE!
LOL; it's voting day today here in Egypt on the constitution changes. Everyone is saying "please vote", even on TV. It's funny seeing it here too :D.


Well I hope you voted, not just for my poll for that other thing too... :P


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 19, 2011, 04:16:37 PM
Yes, but each user will receive same reward in both pools. If a user with high hashing rate will go from one pool to another, his payout will be exactly the same. Same goes for "slow" user.
If the pool was "pay per share" I agree with you. If it was not in theory a pool with 100 members with a 50 ghash/s rate compared to a pool with 1000 members with the same rate the first pool should pay out more because they are solving the same amount of blocks and have to pay it out to lesser amount of people therefore each person would get more BTC. Just like if I two people were mining solo and one has 10x the hash rate he should in theory get 10x as much because 1 pool = 1 miner.
Sorry, but it looks like you don't understand correctly how mining works. Or i don't understand your question :)
If you have 1 GH/s hashing rate, you will receive EQUAL payout per day/week/month in any pool if those pools are working normally.

If there is a pool with 50 users of 1 GH/s each and other pool with 500 users of 0.1 GH/s, their total speed will be the same. And the miners in first pool will get 10x more bitcoins because they are mining 10x faster.
And if there are a pool with 25 users of 1 GH/s and 250 users of 0.1 GH/s, first ones will get 10x more than slow ones, same as if they were in different pools.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 04:43:51 PM
Yes, but each user will receive same reward in both pools. If a user with high hashing rate will go from one pool to another, his payout will be exactly the same. Same goes for "slow" user.
If the pool was "pay per share" I agree with you. If it was not in theory a pool with 100 members with a 50 ghash/s rate compared to a pool with 1000 members with the same rate the first pool should pay out more because they are solving the same amount of blocks and have to pay it out to lesser amount of people therefore each person would get more BTC. Just like if I two people were mining solo and one has 10x the hash rate he should in theory get 10x as much because 1 pool = 1 miner.
Sorry, but it looks like you don't understand correctly how mining works. Or i don't understand your question :)
If you have 1 GH/s hashing rate, you will receive EQUAL payout per day/week/month in any pool if those pools are working normally.

If there is a pool with 50 users of 1 GH/s each and other pool with 500 users of 0.1 GH/s, their total speed will be the same. And the miners in first pool will get 10x more bitcoins because they are mining 10x faster.
And if there are a pool with 25 users of 1 GH/s and 250 users of 0.1 GH/s, first ones will get 10x more than slow ones, same as if they were in different pools.

I understand what you said , and agree , now I'll break it down for you....

TWO POOLS
BOTH POOLS ONLY PAY OUT WHEN A BLOCK IS SOLVED
(no matter what your individual hash rate is you get the same payout as the next guy)
Both Pools have the SAME EXACT overall combined hash rate of their members .
pool #1 has 100 memebers
pool #2 has 100,000 members
both pools solve a block...
Pool #1 distributes the block between its 100 members so each member gets 0.5 BTC
Pool #2 distributes the block between its 100,000 members so each member gets 0.0005 BTC

Since their hash rate is the same they should solve blocks at the same rate. (I know their is the whole "lottery aspect to it" this is just theory)




THIS is why I say a pool with equal payout to all members with a minimum hash rate to join but NO maximum member rate would in theory be the most efficient and optimum way to run a pool...
It is very simple... am I missing something , because this is elementary math here....


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: [Tycho] on March 19, 2011, 04:54:28 PM
Pool #1 distributes the block between its 100 members so each member gets 0.5 BTC
Pool #2 distributes the block between its 100,000 members so each member gets 0.0005 BTC
Each member gets 0.5 BTC only of they all have exactly same hashing speed. If some member has faster rig, it will get bigger reward than others with slower machines.

If a member from pool #1 switches to pool #2, he will get same amount of BTC per day, as in #1 pool.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 04:56:53 PM
Pool #1 distributes the block between its 100 members so each member gets 0.5 BTC
Pool #2 distributes the block between its 100,000 members so each member gets 0.0005 BTC
Each member gets 0.5 BTC only of they all have exactly same hashing speed. If some member has faster rig, it will get bigger reward than others with slower machines.

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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 05:05:20 PM
I think if such a pool was created (every second I am thinking of more details to have it make more sense) it would kick ass.

The rules would be very simple though.

You must meet a minimum hash rate to join, not something low either I am talking over 200mhash/s .
You get equal amount as everyone else.
As long as each account meets the minimum hash rate you can have as many as you like. (Not sure about this yet)
Payouts only occur when blocks are solved.

Why wouldn't this work?


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: LMGTFY on March 19, 2011, 05:06:33 PM
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.



Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 05:32:38 PM
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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: Grinder on March 19, 2011, 05:43:01 PM
What you are describing is a socialist pool. Good luck with that here.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: Thndr on March 19, 2011, 05:49:16 PM
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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: slush on March 19, 2011, 05:51:25 PM
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...

Quote
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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 06:29:46 PM
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...

Quote
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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: slush on March 19, 2011, 07:10:57 PM
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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: jgarzik on March 19, 2011, 07:37:07 PM
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.



Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 07:41:40 PM
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.


Title: Re: Too pool or not to pool? That is the question..+ a poll & poolings effect on BTC
Post by: frankiebits on March 19, 2011, 07:55:03 PM
I am going to take a walk and think.... been on this PC too much today.. :o