BitcoinPool.com open thread

[grndzero]

I've been using this pool for a day and just received my first payout.  So I thought I'd post my experience.
1) So far the payout seems to be in line with my expectations.

It's nice when the sub-1hr blocks hit, especially 2 in a row. There is still the occasional 16-24 hour block so it still evens out.

3) I don't really get the controversy over the efficiency issue.  This is an entirely reasonable thing for a pool to encourage.

With phoenix becoming really popular and managing it's own work queue and other miners improving other pools are going to see some efficiency gains whether they agree with the argument or not.

4) I am concerned about the pool hopping issue.  But the proposed solution seems reasonable and effective.

From what I have seen so far pool speed stays pretty consistent until the 6 hour mark then a lot of people hop out. Since there's not a graph of speed/round time or json data for the pool you can't be sure, but I end up checking it a lot and don't see a lot of big changes in within average round times.

5) The website isn't great.  It's impossible to navigate.  Why are the stats on the front page?  It took me almost a day to figure out what the statistics meant.  Estimated payouts are wildly inaccurate.  Since I joined at the end of a block, for the first few hours I was convinced I had hit some kind of Bitcoin jackpot.  Alas, that was not the case.

They wanted to be as open as possible with the data, so it's right out front. Estimated payouts are (your submitted shares/total submitted shares), they vary a lot at the beginning of the round. I don't see mine vary that much after the round has been going for a while.

6) Not encrypting passwords is dumb and will likely end up being a dealbreaker for my continued use.

This was fixed over a week (or two) ago now. I never had a problem with my account. I changed the password once after the compromise, and change it occasionally for good measure, and check to make sure my address hasn't changed occasionally also. It's really not that big of a deal for me.

Happy Mining

[benjamindees]

I was actually referring to encryption of the account login page.

But I have some more concerns with the stats.  Errors like this one make me wonder whether shares are being calculated correctly.



Also, poclbm-mod shows my hashrate as at least 300 Mh/s every time I look, yet my account page varies wildly and is regularly as low as 200 Mh/s.  What is the explanation for this?

[bobR]

well their efficiency  bs is starting to take toll
with increased difficulty and Long poll  they no longer tolerate cpu miners or any slow gpu's
they just want the fast ...  and those that can't see what they do

how the He.. is mining every list bit of a get work efficient for the miner
continue hashing on bad getworks or those with no reward

and then deal with fifth grad math math skills
oh it's a mistake
excuses & down right lies ... well it will get better
abuse from the ... people in charge
they do little more than bad mouth anyone the has the BALLS to speak up
guess what it's not better it got BAD

after 2 months ...  may they do well

oh we give stuff away for the screw job we give .. more promises
do we lie & fU ...dua

[slush]

But I have some more concerns with the stats.  Errors like this one make me wonder whether shares are being calculated correctly.

To be correct - yes, this is possible. There can be more valid responses for one getwork request.

[grndzero]

Also, poclbm-mod shows my hashrate as at least 300 Mh/s every time I look, yet my account page varies wildly and is regularly as low as 200 Mh/s.  What is the explanation for this?

They have abandoned poclbm-mod in favor of phoenix.

[benjamindees]

There can be more valid responses for one getwork request.

Okay I see that now.  That makes sense.

Any insight on the hashrate issue?  I ran a log for several minutes and it shows an average of 320 Mh/s.  The website shows something around 250 Mh/s.  I can't be the only one to notice this.

[keybaud]

well their efficiency  bs is starting to take toll

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?

[grndzero]

There can be more valid responses for one getwork request.

Okay I see that now.  That makes sense.

Any insight on the hashrate issue?  I ran a log for several minutes and it shows an average of 320 Mh/s.  The website shows something around 250 Mh/s.  I can't be the only one to notice this.

Every site does that. The site is not in direct contact with the mining client as to how fast it is processing, so it uses math to try to make a guess on depending how fast you submit results. If you submit a few valid responses at a time it looks like you are submitting more than the average speed of the client so the math says you're faster than you are.

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

[benjamindees]

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

Wouldn't you say that's kind of a huge efficiency hit (1/3)?  I consistently see values that are 1/4 less than what my local client shows.  Isn't the value on the website an average (over 5 min)?

[1bitc0inplz]

well their efficiency  bs is starting to take toll

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?

The B.S. part is his attitude and how he bans just about any CPU miner. Statistically speaking there is no good reason for worrying about "efficiency".

[grndzero]

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

Wouldn't you say that's kind of a huge efficiency hit (1/3)?  I consistently see values that are 1/4 less than what my local client shows.  Isn't the value on the website an average (over 5 min)?

That's speed, not efficiency. If you are seeing values that low try restarting your client(s). I'm seeing an unusually high "queue empty, miner idle" messages on my phoenix clients, could be bitcoinpool getting hit really hard with ddos today or something going on in the system.

The average is supposed to be 5 minutes, yes. I saw the same swings both ways on all sites that I have been on, I have been on 3 different sites in the past 2 months.

[grndzero]

well their efficiency  bs is starting to take toll

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?

The B.S. part is his attitude and how he bans just about any CPU miner. Statistically speaking there is no good reason for worrying about "efficiency".

They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there. If you used a client that let you set the askrate so that it fulfilled the efficiency requirement they would probably allow it to run on their site.

[1bitc0inplz]

They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

[keybaud]

They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

A $100 video card will get you 350 MH/s, so by your maths it will take 420 CPU miners to equal one GPU miner. The GPU miner will be running at 90% efficiency, whereas the slow speed of the CPU will make it worse. This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner. The idea of bitcoinpool is that they try to make every block count.

[grndzero]

They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

Before I bought video cards I put my CPU on there and watched it and it was terrible. It was grabbing up a lot of getworks that it was never going to process through. After about a half hour I just shut it down because it was ugly.

80 MH sounds pretty small compared to the size of the smallest pools and easily done with a low end graphics card. If that was coming from 1 person that wanted to try it and could tune the efficiency to meet the requirements then it might be worth it to them. Trying to manage 100 clients at 800 kH/s would be not be a advantageous unless there was a miner that managed cpu efficiency for them like the new generation of gpu miners are doing.  

[1bitc0inplz]

A $100 video card will get you 350 MH/s, so by your maths it will take 420 CPU miners to equal one GPU miner. The GPU miner will be running at 90% efficiency, whereas the slow speed of the CPU will make it worse. This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner. The idea of bitcoinpool is that they try to make every block count.

And... explain to me how turning away free workers makes "every block count"?

[benjamindees]

And... explain to me how turning away free workers makes "every block count"?

Perhaps their network connection is limited.

[grndzero]

And... explain to me how turning away free workers makes "every block count"?

Perhaps their network connection is limited.

It doesn't take much bandwidth to maintain a client. I think I saw somewhere tyco said something like 10 kb/s per client. The issue is that cpu miners are fractions slower than gpu's and if they are requesting work at the same rate then they are eating up valid getworks and never processing through them all.

[1bitc0inplz]

It doesn't take much bandwidth to maintain a client. I think I saw somewhere tyco said something like 10 kb/s per client. The issue is that cpu miners are fractions slower than gpu's and if they are requesting work at the same rate then they are eating up valid getworks and never processing through them all.

Correct on the getwork requests being small.

However, if BitcoinPool is implement so that every client is operating off the same private key, then this is a failure with the way they implemented their pool.

If every client is operating on their own private key (which, by "their own" I mean one generated for them and known only by BitcoinPool), then they would never have this problem you are speaking of.

In addition to nonce, the hash varies based on timestamp and private key (already discussed). So, in theory, every second a new "address space" (as you've called it) opens up. Not to mention, if every client IS operating off the same private key, then they are duplicating efforts. The miner client picks their nonce range, not the pool.

My guess is that they do use multiple private keys.

[xenon481]

This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner.

This is not true. Period. MHash/sec is MHash/sec. It doesn't matter how many clients it required to do that. It doesn't matter how many getworks. It especially doesn't matter how far into the getwork a client processes before starting a new one. Over time, they will ALL find the same number of solutions per MHash/sec in the same time period.

The idea of bitcoinpool is that they try to make every block count.

No, the idea of bitcoinpool's "efficiency" is to reduce the amount of server processing and bandwidth load.  This load is absolutely minimal.

Before Long Polling came around, working the entire getwork was idiotic because of the increase in stale shares (especially for a CPU miner!), but now that most of the pools support Long Polling, there is no reason for the miners not to reduce the server load in this manner.

But doing so does absolutely nothing for the miner and DOES NOT increase the number of shares that you find.