BitcoinPool.com open thread - page 2.

grndzero

sr. member

Activity: 392

Merit: 250

Quote from: 1bitc0inplz on May 14, 2011, 06:05:39 PM

Quote from: grndzero on May 14, 2011, 05:56:54 PM

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.

keybaud

full member

Activity: 120

Merit: 100

Quote from: 1bitc0inplz on May 14, 2011, 06:05:39 PM

Quote from: grndzero on May 14, 2011, 05:56:54 PM

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.

1bitc0inplz

member

Activity: 112

Merit: 10

Quote from: grndzero on May 14, 2011, 05:56:54 PM

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.

grndzero

sr. member

Activity: 392

Merit: 250

Quote from: 1bitc0inplz on May 14, 2011, 05:43:50 PM

Quote from: keybaud on May 14, 2011, 05:14:48 PM

Quote from: bobR on May 14, 2011, 04:26:44 PM

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.

grndzero

sr. member

Activity: 392

Merit: 250

Quote from: benjamindees on May 14, 2011, 05:30:23 PM

Quote from: grndzero on May 14, 2011, 05:16:49 PM

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.

1bitc0inplz

member

Activity: 112

Merit: 10

Quote from: keybaud on May 14, 2011, 05:14:48 PM

Quote from: bobR on May 14, 2011, 04:26:44 PM

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

benjamindees

legendary

Activity: 1330

Merit: 1000

Quote from: grndzero on May 14, 2011, 05:16:49 PM

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)?

grndzero

sr. member

Activity: 392

Merit: 250

Quote from: benjamindees on May 14, 2011, 05:12:25 PM

Quote from: slush

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.

keybaud

full member

Activity: 120

Merit: 100

Quote from: bobR on May 14, 2011, 04:26:44 PM

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?

benjamindees

legendary

Activity: 1330

Merit: 1000

Quote from: slush

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.

grndzero

sr. member

Activity: 392

Merit: 250

Quote from: benjamindees on May 14, 2011, 04:04:05 PM

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: benjamindees on May 14, 2011, 04:04:05 PM

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.

bobR

member

Activity: 112

Merit: 10

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

benjamindees

legendary

Activity: 1330

Merit: 1000

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?

grndzero

sr. member

Activity: 392

Merit: 250

Quote from: benjamindees on May 11, 2011, 06:58:31 PM

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.

Quote from: benjamindees on May 11, 2011, 06:58:31 PM

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.

Quote from: benjamindees on May 11, 2011, 06:58:31 PM

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.

Quote from: benjamindees on May 11, 2011, 06:58:31 PM

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.

Quote from: benjamindees on May 11, 2011, 06:58:31 PM

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

legendary

Activity: 1330

Merit: 1000

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.

2) Uptime isn't perfect, but it's good enough. No complaints considering all the DDOSsing going around.

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

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

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.

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

dishwara

legendary

Activity: 1855

Merit: 1016

Seems, victim is to get punishment.
dishrag cleans mess created by others & it doesn't create mess.
I apologizes to the bitcoinpool.com & their members that it is/was my fault for not checking out my account with correct password & wallet id.
Instead of checking my account & securing myself i made an accusation that made many members time, money wasted & also created unnecessary problems.

I deeply from my heart apologize to all the members for creating a mess, instead of solving it myself.
Sorry.

bobR

member

Activity: 112

Merit: 10

Seeing everyone was aware of the "breakin / hacking"
Just who is to blame for not checking your account's accuracy?
How are The pool operators supposed to know what your bit coin address should be ??

I think even if they didn't say to you would change your password and make sure the coins were going to your account knowing that someone else's accounts had been compromised.

cdhowie

full member

Activity: 182

Merit: 107

Quote from: geebus on May 08, 2011, 11:29:12 PM

It's possible that you left around the same time that we starting logging each ban independently based on reason and your ban was mis-categorized. I didn't say you were wrong, I said our logs showed otherwise, stating, in hand, that upon inspecting your account history and our logs, it showed that you were banned for low efficiency. A lot of those logs were recategorized by hand when we first implemented the system.

Fair enough. The logs are simply wrong. However, let me return to the point I was trying to make (and that you seem to only be helping me make):

Quote from: geebus on May 08, 2011, 06:22:29 AM

The only people who seem to dislike, distrust, or belittle our pool are those who haven't tried it themselves.

This is a demonstrably false wide-sweeping statement. I am one counter-example; there are likely others. It's best to avoid making categorical statements of the form "All S are P" unless you can prove it.

Quote from: geebus on May 08, 2011, 10:37:24 AM

Upset because we banned you for being inefficient?

It's a rule. You broke it.

A rush to judgement, using data generated from code that you have since admitted you knew to be buggy.

Now, to return to your latest reply:

Quote from: geebus on May 08, 2011, 11:29:12 PM

It says nothing about the rest of the pool functionality or code, nothing about my ability to be logically competent, and doesn't say that I'm lying either.

You're right there. But this combined with the SQL injection vulnerability that was already exploited only furthers my case for avoiding your pool. Where there's smoke...

Quote from: geebus on May 08, 2011, 11:29:12 PM

However, if you choose to read that far into it, I can into you saying that by choosing to leave a pool that has no fees, consistently improves and implements new features, and grows on a daily basis in favor of any of the other options that were available a month ago, you're displaying that you personally are not capable of doing basic math in regard to net gains, as is the case with the better portion of the bitcoin community, as they left one pool that charges excess fees for another that charges even more.

The pool I'm in takes a flat fee of 0.02592 BTC from the entire pool per 30 days, which is less than 0.01 BTC when you consider that it is divided among all workers. Again, you rush to judgement without getting your facts straight. I don't think I can make my point any better than you already have.

nster

full member

Activity: 126

Merit: 100

Quote from: keybaud on May 09, 2011, 07:39:26 AM

Quote from: dishwara on May 09, 2011, 04:28:04 AM

Its not my fault, i am not asking you to pay me.
You seems not understanding still.
They didn't change password, they changed ADDRESS.
Since Bitcoin address is not a number very very very very easy to remember, it is very hard to find whether it is changed or not.
The hacker hacked members account & changed the address, so that he gets bitcoins, not members.
This is not about password only, its about ADDRESS also & address is very very very very important than password here in bitcoin world.

The email i received from you only tells to change password, not saying anything about address checking, verifying & confirming.

People were told to check their wallet IDs and the pool owners halted all payments for a couple of days to allow compromised accounts to check their payment address, thus preventing payment to any changed accounts. 5th post quoted from bitcoinpool forum thread that was linked in large red text on the front page:

Quote from: FairUser

The same ###### #####(s) tried to brute force into accounts again last night.
I just blocked the entire /16 netblock for their entire ISP.

CHECK YOUR WALLET ID'S RIGHT NOW!!!!
IF YOUR PASSWORD IS THE SAME AS YOUR USERNAME, THEN YOU NEED TO CHANGE IT NOW.

The pool owners have worked very hard to try and ensure that they and all pool users update and secure their accounts after the initial attack.

While I don't trust bitcoinpool operators at all, this is true, they did say to check wallet addresses

Topic: BitcoinPool.com open thread - page 2. (Read 29840 times)