[NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)

[grue]

I'm not sure why, but this pool seems to have lower earnings than slush's pool. after crunching some data from slush's pool, i found out that i make around 0.03 BTC per hour mining. However, i ran a miner for 1 entire day, and the "estimated earnings" is only 0.06 BTC.

[1713997335]

1713997335

[1713997335]

1713997335

[Braidcutter]

I'm not sure why, but this pool seems to have lower earnings than slush's pool. after crunching some data from slush's pool, i found out that i make around 0.03 BTC per hour mining. However, i ran a miner for 1 entire day, and the "estimated earnings" is only 0.06 BTC.

Probably right, but in order to get a true read, you will need to run in this pool for an entire round. Stick with it till the round after this one completes. Then you can be sure of your earnings.

[geebus]

Base lies I say. I understand the need for keeping long-poll alive, so wouldn't it be more useful just to do so, and not call another getwork.

No.  
If my video card can do 200,000,000 hash/s, and there are 4,294,967,296 (2^32) possible hashes in a getwork, it would take ~21 seconds to go through all the (2^32) possible hashes.
After that 21 seconds, what would we do without another getwork? Nothing.  
Hence, this is why you need to get another getwork from the server.

Long polling was designed to tell the miner "Yeah, the block just changed on us, stop what you're working on, and here is a new getwork for you to start working on."

Okay, another newb question then. Is it possible to hand out larger (say 64-bit) getworks. Or is this a limitation of Bitcoin. Only thinking of ways to make faster clients less taxing on the server. With long-poll in play there is no reason to pester the server until the server says otherwise.

yay, %10000 eff for everyone!

It could potentially be feasible to do so, but realistically, if a client is asking for work only when they need it, even on extremely fast GPUs, it would still be one request every few seconds.

One request every few seconds * ~30 active users is around 20k bandwidth... not much at all... but when you add in a few cpu miners or slow gpu miners that are asking for new work once per second because they think it will help them find shares faster, you've now got ~20k bandwidth for the whole of the active pool, and then an additional ~50-80k bandwidth just for the 5 or 6 guys requesting getworks non-stop.

It's still not a drastic amount of bandwidth by any means, considering the server is on a 50 mbp/s fiber line, but it's still going overboard on asking for new work, and at that point, actually hurting your chances of finding a share, since you're scanning only 1/100th (give or take, based on speed) of the hash space before moving on. To put some perspective on it, my CPU gets ~8 Mhash/s... which would take me 537 seconds to work through an entire getwork.

So, if I set an askrate of 1 second, I'm only looking at 0.187% (and probably even less than that due to overhead, server transmit, etc) of the getwork every time and still expecting to find an answer.

64-bit getworks would be going overboard I think, but having some of these CPU miners with ridiculously low askrates change them to even 5 or 10 seconds would dramatically cut down the additional bandwidth usage required to support them. Otherwise, they're basically just a burden on the pool, as they contribute a few dozen shares, at most, while requesting work tens of thousands, or in some cases, hundreds of thousands of times, using the same amount of bandwidth per user as the rest of the pool combined.

[geebus]

I'm not sure why, but this pool seems to have lower earnings than slush's pool. after crunching some data from slush's pool, i found out that i make around 0.03 BTC per hour mining. However, i ran a miner for 1 entire day, and the "estimated earnings" is only 0.06 BTC.

slush's pool and our pool use completely different scoring mechanisms. We pay based on an equal proportion system.

Your payout = the number of shares you submit / the total number of shares in the round

slush's pool is weighted shares, where as the round progresses, the newest shares hold the highest value, and older shares slowly lose value.

There are other factors that can also be reflected in observed payout, such as the number of shares submitted over X amount of time, the askrate being used, on what miner, speed of the card/cpu, etc...

Observing for even a few hours is likely too small of a dataset to determine actual results, since your payout is also based on those same factors for everyone else on the pool. Your card may have been finding shares at a slower rate, just getting a lot of getworks that didn't have answers, while someone else's card may have been having the opposite occur, which would reduce your payout as the total number of shares for the round increases, and your submitted shares stayed the same.

We tested our pool based on datasets of two weeks of constant mining from either pool and found the payout over time to be identical.

slush's pool solves more blocks per day, but splits the payout over a much larger number of users. We solve less blocks per day, but split the payout over far less users, which equals out over time.

Likewise, slush's pool charges a fixed donation rate of 2%, whereas we charge 0%. So, when observing the estimated earnings on slush's pool, you need to take the 2% donation into consideration.

I recommend watching for a few weeks on either pool and then determining, based on an average of the actual payouts, and not estimated earnings, whether or not the payouts are equal.

But, with different scoring mechanisms you're kind of trying to compare apples to oranges. They're both fruit, but intrinsically different.

[[Tycho]]

It's still not a drastic amount of bandwidth by any means, considering the server is on a 50 mbp/s fiber line, but it's still going overboard on asking for new work, and at that point, actually hurting your chances of finding a share, since you're scanning only 1/100th (give or take, based on speed) of the hash space before moving on.

How that can hurt your chances in any way ?
There is no difference except for work change overhead in singre-threaded miner which is negligible anyway.

[rasputin]

I'm not sure why, but this pool seems to have lower earnings than slush's pool. after crunching some data from slush's pool, i found out that i make around 0.03 BTC per hour mining. However, i ran a miner for 1 entire day, and the "estimated earnings" is only 0.06 BTC.

It's been ~2 days since this pool got a block, which means right now you're up against users that have put a lot of work in and earned plenty of shares. Because of this, your BTC/hour will be lower than in slush's pool until BitcoinPool gets lucky again.

Once a new round starts, you'll earn 2% more BTC/hour here, as slush takes a fee while this pool doesn't.

[geebus]

It's still not a drastic amount of bandwidth by any means, considering the server is on a 50 mbp/s fiber line, but it's still going overboard on asking for new work, and at that point, actually hurting your chances of finding a share, since you're scanning only 1/100th (give or take, based on speed) of the hash space before moving on.

How that can hurt your chances in any way ?
There is no difference except for work change overhead in singre-threaded miner which is negligible anyway.

It hurts your chances because you don't find anything unless it's with the first iteration of the CL kernel. It's a response based on observation of thousands of submitted shares, and how many of those were found in the first 1% of the getwork. If you don't search, you wont find, plain and simple.

[xenon481]

It's still not a drastic amount of bandwidth by any means, considering the server is on a 50 mbp/s fiber line, but it's still going overboard on asking for new work, and at that point, actually hurting your chances of finding a share, since you're scanning only 1/100th (give or take, based on speed) of the hash space before moving on.

How that can hurt your chances in any way ?
There is no difference except for work change overhead in singre-threaded miner which is negligible anyway.

It hurts your chances because you don't find anything unless it's with the first iteration of the CL kernel. It's a response based on observation of thousands of submitted shares, and how many of those were found in the first 1% of the getwork. If you don't search, you wont find, plain and simple.

You obviously don't understand how all of this works. The distribution is normalized. The odds that a solution is in the first 1% of the GetWork is exactly the same as if it is in the second 1% of the GetWork and is exactly the same as if it is in the 100th 1% of the GetWork.

If you truly believe that you have better odds of finding a solution by searching 100,000,000 sequential possibilities as opposed to 100,000,000 random possibilities, then that means that you believe that SHA256 is broken and predictable.

[h00ters]

I'm not sure why, but this pool seems to have lower earnings than slush's pool. after crunching some data from slush's pool, i found out that i make around 0.03 BTC per hour mining. However, i ran a miner for 1 entire day, and the "estimated earnings" is only 0.06 BTC.

Slush is taking BTC from the top when no one watches..... plus he has forced donations cause he a fucking douch! So there goes those earnings you just made.

This pool is prolly the most optimized from what I've seen. admins are pretty active too.

RTFM, search the forums. If you cant find yer answer, ask and I'm sure someone will chim in.

[FairUser]

Okay, another newb question then. Is it possible to hand out larger (say 64-bit) getworks. Or is this a limitation of Bitcoin. Only thinking of ways to make faster clients less taxing on the server. With long-poll in play there is no reason to pester the server until the server says otherwise.

Yes, we could do that if we wanted to.

[geebus]

You obviously don't understand how all of this works. The distribution is normalized. The odds that a solution is in the first 1% of the GetWork is exactly the same as if it is in the second 1% of the GetWork and is exactly the same as if it is in the 100th 1% of the GetWork.

If you truly believe that you have better odds of finding a solution by searching 100,000,000 sequential possibilities as opposed to 100,000,000 random possibilities, then that means that you believe that SHA256 is broken and predictable.

Do me a favor next time you post, and read back what you wrote before you hit submit, because you have a tendency to assume I mean something that I never said, and put words in my mouth according to your assumptions.

I've never said SHA256 is broken, and I've never once said it was predictable. However, from analysis of the data that I have personally gathered, thousands of shares worth of data, I notice a significantly lower amount of shares being found in the first 0 - 1% of a hashspace.

Likewise, even using your own words as the basis of argument, I could say that, if you had the same chance to find an answer at 1% as you do at 100% of the getwork, there is absolutely no fucking reason that you should set your askrate to 1 second. 

Lets put an end to the debate and leave it at this...

It's my preference to have miners on my pool not use an askrate of 1 second, and because it is my preference, I will reserve the right to ban them for having a 1 second askrate. Likewise, you don't participate in my pool, and I reserve the right to ignore anything and everything that you say in the future, because it is my preference to think you're an ass. That is my preference. Debate over.

[xenon481]

I've never said SHA256 is broken, and I've never once said it was predictable. However, from analysis of the data that I have personally gathered, thousands of shares worth of data, I notice a significantly lower amount of shares being found in the first 0 - 1% of a hashspace.

Again, you are saying that you have proof (or at least strong enough circumstantial evidence to convince you) that SHA256 is predictable within tolerances... If you have evidence that "a significantly lower amount of shares being found in the first 0 - 1%", then you should skip processing the 0-1% area entirely and only process the other areas that have better solution rates.

Likewise, even using your own words as the basis of argument, I could say that, if you had the same chance to find an answer at 1% as you do at 100% of the getwork, there is absolutely no fucking reason that you should set your askrate to 1 second. 

The ONLY reason to have an askrate lower than 60 seconds is to poll the pool server to make sure that the block being processed hasn't changed (to protect yourself from Stales). With long polling (push), the need to do periodic polling goes away entirely. That is the entire point of long polling.

And I don't know of ANYBODY that has ever advocated askrate being set to 1 second. The various mining programs have (had before long polling) varying defaults from 5 to 10 to 15. Now with long polling, it is set to 60 seconds in order to include new transactions in the same block.

[geebus]

And I don't know of ANYBODY that has ever advocated askrate being set to 1 second. The various mining programs have (had before long polling) varying defaults from 5 to 10 to 15. Now with long polling, it is set to 60 seconds in order to include new transactions in the same block.

I never said anyone advocated it. I said people are DOING it.

You're basing all of your assumptions about SHA256 on a perfect environment, but there are MANY variables that come into play that could cause a flux in results. The miner, the cl kernel, it's implementation of SHA256, the card itself, the driver, the OS, etc... each of these could be having an effect on the ability of a miner to actually process the full one percent in a matter of seconds. It's based on the hash speed of the card, and whether or not it can even process a full iteration of the CL kernel before the askrate is met and it dumps it's current work to grab new work.

I've never once stated, EVER, that SHA256 is flawed... I have on the other hand stated that, observationally, the miner itself is not generating perfectly distributed results.

THE MINER. Not SHA256.

So, fuck you very much, and STFU.

[xenon481]

I've never once stated, EVER, that SHA256 is flawed... I have on the other hand stated that, observationally, the miner itself is not generating perfectly distributed results.

THE MINER. Not SHA256.

Wait, so now you are saying that you believe that the mining programs which run the exact same code on every single possibility in the getwork do not produce the work exactly right for the first X times that the loop is processed (on average), but they do work properly after that and that this anomalous error of the mining software resets with every getwork request?

[FairUser]

And I don't know of ANYBODY that has ever advocated askrate being set to 1 second. The various mining programs have (had before long polling) varying defaults from 5 to 10 to 15. Now with long polling, it is set to 60 seconds in order to include new transactions in the same block.

I never said anyone advocated it. I said people are DOING it.

You're basing all of your assumptions about SHA256 on a perfect environment, but there are MANY variables that come into play that could cause a flux in results. The miner, the cl kernel, it's implementation of SHA256, the card itself, the driver, the OS, etc... each of these could be having an effect on the ability of a miner to actually process the full one percent in a matter of seconds. It's based on the hash speed of the card, and whether or not it can even process a full iteration of the CL kernel before the askrate is met and it dumps it's current work to grab new work.

I've never once stated, EVER, that SHA256 is flawed... I have on the other hand stated that, observationally, the miner itself is not generating perfectly distributed results.

THE MINER. Not SHA256.

So, fuck you very much, and STFU.

++

Geebus is not saying that the mining programs *are* missing the first 1% of the getwork, he's saying he (and myself) has *observed* this when looking at the recorded getwork's from a log and *believe* that something is not right here.  This causes us to wonder, so we research further to figure out why this is happening.  You are right that it should be a nice, even distribution of answers from 1% to 100%, but what we are *observing* is NOT a perfect distribution.

We never made such an outrageous claim as to breaking SHA256.  You are the one implying we broke SHA256 when we have never said that.
We are saying what we are observing, and we are observing a far less than perfect distribution of shares found at 1% of the getwork...that's all. 

Quit trying to put words in our mouth with outrageous claims in an attempt to discredit what we're observing. Instead of talking trash, why don't you download the miner, log about 30000+ shares submitted, and get back to us with those results.  The more results we can collect, the better chance we have at figuring our what is causing this observed behavior.

If you're not going to do any research yourself or anything other than trying to make false claims on our behalf, then do yourself, us, and everyone else a favor and say nothing.

[Braidcutter]

Okay, another newb question then. Is it possible to hand out larger (say 64-bit) getworks. Or is this a limitation of Bitcoin. Only thinking of ways to make faster clients less taxing on the server. With long-poll in play there is no reason to pester the server until the server says otherwise.

Yes, we could do that if we wanted to.

64-bit getworks would be going overboard I think, but having some of these CPU miners with ridiculously low askrates change them to even 5 or 10 seconds would dramatically cut down the additional bandwidth usage required to support them. Otherwise, they're basically just a burden on the pool, as they contribute a few dozen shares, at most, while requesting work tens of thousands, or in some cases, hundreds of thousands of times, using the same amount of bandwidth per user as the rest of the pool combined.

If my video card can do 200,000,000 hash/s, and there are 4,294,967,296 (2^32) possible hashes in a getwork, it would take ~21 seconds to go through all the (2^32) possible hashes.
After that 21 seconds, what would we do without another getwork? Nothing. 
Hence, this is why you need to get another getwork from the server.

Long polling was designed to tell the miner "Yeah, the block just changed on us, stop what you're working on, and here is a new getwork for you to start working on."

Okay okay, point taken. Just to say FairUser claims a 200mh/s GPU and he is by far in the minority on his own pool. Most actives are pulling down < 70. So it seemed right to me.

After reviewing the math 64-bits is a bit much. Even 8 more bits up to 40-bit would silence his client. And lower the gets to within block speed, for ~8 years.

oh And:

It's my preference to have miners on my pool not use an askrate of 1 second, and because it is my preference, I will reserve the right to ban them for having a 1 second askrate. Likewise, you don't participate in my pool, and I reserve the right to ignore anything and everything that you say in the future, because it is my preference to think you're an ass. That is my preference. Debate over.

Praise Geebus. Amen.

[slush]

Geebus is not saying that the mining programs *are* missing the first 1% of the getwork, he's saying he (and myself) has *observed* this when looking at the recorded getwork's from a log and *believe* that something is not right here.  This causes us to wonder, so we research further to figure out why this is happening.  You are right that it should be a nice, even distribution of answers from 1% to 100%, but what we are *observing* is NOT a perfect distribution.

Correct me if I'm wrong, but you probably invented new scientific method called 'believing'. Miner IS sha256 cruncher. So you're talking about two possibilities:

a) sha256 is broken
b) something serious in miners is broken

Give us statistics, not claims; then many smart people start to repairing the wrong miners. But you are talking about efficiency, improvements, bugs here and there, but you never show any real materials to confirm that. Well, except pretty excel sheet with two graphs showing that there is more shares in job with many nonce tries. wow.

We never made such an outrageous claim as to breaking SHA256.  You are the one implying we broke SHA256 when we have never said that.
We are saying what we are observing, and we are observing a far less than perfect distribution of shares found at 1% of the getwork...that's all. 

So show me exact statistics. As you have collected milions of shares to confirm that, this won't be surely a problem.

To be correct, I _did_ the analysis with ~15 milions of shares on end of January and I can say that shares are perfectly spreaded inside whole nonce range. So this is the reason why I don't believe you.

[FairUser]

So show me exact statistics. As you have collected milions of shares to confirm that, this won't be surely a problem.

To be correct, I _did_ the analysis with ~15 milions of shares on end of January and I can say that shares are perfectly spreaded inside whole nonce range. So this is the reason why I don't believe you.

I'm not up to a million yet, but I'll let you know when I am.
Oh, 15 million....care to share them?  If you do, that would shut us up.  Here's you chance to put this to bed ...

[FairUser]

Correct me if I'm wrong, but you probably invented new scientific method called 'believing'. Miner IS sha256 cruncher. So you're talking about two possibilities:

What we currently believe personally is not a scientific method.  If the data changes and shows something else, then our believes could change.

So show me exact statistics. As you have collected milions of shares to confirm that, this won't be surely a problem.

To be correct, I _did_ the analysis with ~15 milions of shares on end of January and I can say that shares are perfectly spreaded inside whole nonce range. So this is the reason why I don't believe you.

I'm not up to a million yet, but I'll let you know when I am.
Oh, 15 million....care to share them?  If you do, that would shut us up.  Here's you chance to put this to bed ...

[bobR]

Wish this round was over
added a couple machines
I'll have to wait and see what that means
now its now down to can you keep up (do enough crunching) with added shares
..and added users
hope it gets done soon