Pages:
Author

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

full member
Activity: 140
Merit: 100
July 18, 2013, 06:20:38 PM
Looks like bitcoinpool.com may be dead finally. Looks like they've found two blocks in the last three months and haven't paid out on either of them. According to their forum sigs, the admins aren't even mining there anymore and no one is responding to forum posts asking about the status of payment.

They are well-reputed enough and ran the pool long enough that I'm not accusing them of taking the money and running, but it does look like they've gone home and aren't bothering with keeping the pool alive anymore. It might be best if they'd stop accepting miners' hashes if they aren't going to bother paying out.
sr. member
Activity: 406
Merit: 250
June 16, 2011, 08:45:07 AM
Once again, the owners of this pool make factually incorrect statements in order to promote fear, uncertainty, and doubt.

Quote
[...] now that pool speed has increased without any noticable increase in our blocks-per-day average due to significantly decreased efficiency.

What the pool owners call "efficiency" (server load) has absolutely no relationship with how many blocks-per-day the pool finds. The reason for the same number of blocks-per-day is because difficulty has gone up.

Quote
When your efficiency is low, you are skipping over potential answers that could solve the block. Those potential answers, had the getwork not been provided to inefficient users, could have been submitted if that getwork had gone to an efficient user, resulting in a block being solved by the pool.

That doesn't matter one single bit. The odds of you finding a block are the exact same no matter if you complete that getwork or if you ask for a new one.
legendary
Activity: 1855
Merit: 1016
June 02, 2011, 04:20:23 PM
From bitcoinpool.com
Quote
Service Outage Fixed
Posted on: 06-02-2011 20:00:16

We had a regional outage for a couple of hours.  Service is back online.  Sorry for the interruption. Anti Pool-hopping will disabled for this round.  Thank you.
member
Activity: 105
Merit: 10
Spreading Bitcoin love
June 02, 2011, 01:42:06 PM
Down for me too.
full member
Activity: 120
Merit: 100
June 02, 2011, 11:34:54 AM
Is this pool down?

It's down for me, at the moment, which is a shame, as I was still playing with their new website..
full member
Activity: 139
Merit: 100
June 02, 2011, 11:23:02 AM
Is this pool down?
newbie
Activity: 47
Merit: 0
May 26, 2011, 11:46:36 AM
I see.
Thanks for this clarification.
newbie
Activity: 3
Merit: 0
May 26, 2011, 10:41:18 AM
take half, of which half is re-distributed back into the pool
[Citation needed]  Smiley
From what I can read on their forum, they don't seem to redistribute those shares:
Quote from: Geebus
If the time difference between their shares is less than one half of the round duration, their share count will be reduced by 50% and the other half of their shares will be credited to an account setup by the pool operators.

"I did change the code so that in the event of a long round (6 hours or more) then the way shares are redistributed changes. Instead of cutting each pool hopping users by half, and then distributing 1/2 of that remainder to both FairUser and Myself, it will distribute 1/4 to both FairUser and Myself, and then remove the remaining 1/4 of the shares from the round. This will cause everyone else's share value to increase."

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=103&start=40

4th post on the page.  In all fairness I did have it slightly wrong as 1/4 of the shares are eliminated as opposed to being redistributed back into the pool, but it has more or less the same effect in terms of how much they are taking and how the rest of the pool is affected.  Also,  it's not like they are just pocketing that cash: http://www.bitcoinpool.com/forum/viewtopic.php?f=7&t=125
 
newbie
Activity: 47
Merit: 0
May 26, 2011, 01:31:21 AM
take half, of which half is re-distributed back into the pool
[Citation needed]  Smiley
From what I can read on their forum, they don't seem to redistribute those shares:
Quote from: Geebus
If the time difference between their shares is less than one half of the round duration, their share count will be reduced by 50% and the other half of their shares will be credited to an account setup by the pool operators.
newbie
Activity: 3
Merit: 0
May 25, 2011, 09:42:50 PM
Well if by "do what they please" you mean "enforce the 30% rule", by "change their mind as frequently as I take a leak" you mean "announce all rule changes, which are infrequent, clearly in the pool news subsection of their forums", and by "now they take half of anyone that they deem by their determination to be pool hopping" you mean "take half, of which half is re-distributed back into the pool, from people who participate in less than 50% of a given round as determined by their first and last submitted shares, which is actually more fair to non-dedicated miners than a score-based system", then I agree with you completely.

member
Activity: 112
Merit: 10
May 25, 2011, 02:32:21 PM
Could some please tell me what an acceptable efficeincy figure is for this pool? I've just started and I am currently at about 65% and I fear this may be too low.

Is there a way to increase my efficeincy with GUI miner? I know it is recommended to use pheonix but I currently do not have the time or sufficient knowledge to setup this up. I know the information is out there to do it but my keyboard doesn't have a working forward slash key at the moment which makes command lines impossible. I could probably tie it to another key in some way but I dont know how. To find out just further adds to the time issue.

I will eventually move to pheonix as it seems to produce better figures but for now I need to make do with GUI miner.

They say 30% but they are pricks and do what they please
They change their mind as frequently as I take a leak
and now they take half of anyone that they deem by their determination to be pool hopping
so much for FREE ... no fee

FYI spent the $10 and get a keyboard
member
Activity: 69
Merit: 10
May 25, 2011, 02:30:11 PM
I did go over there but some sort of error came up when I tried to use the search function. I'll go have another look.
sr. member
Activity: 392
Merit: 250
May 25, 2011, 02:16:12 PM
Could some please tell me what an acceptable efficeincy figure is for this pool? I've just started and I am currently at about 65% and I fear this may be too low.

Is there a way to increase my efficeincy with GUI miner? I know it is recommended to use pheonix but I currently do not have the time or sufficient knowledge to setup this up. I know the information is out there to do it but my keyboard doesn't have a working forward slash key at the moment which makes command lines impossible. I could probably tie it to another key in some way but I dont know how. To find out just further adds to the time issue.

I will eventually move to pheonix as it seems to produce better figures but for now I need to make do with GUI miner.

I think the lower limit is somewhere around 60%, I'm not absolutely sure though. You can ask on the bitcoinpool.com/forum though.
member
Activity: 69
Merit: 10
May 25, 2011, 02:01:57 PM
Could some please tell me what an acceptable efficeincy figure is for this pool? I've just started and I am currently at about 65% and I fear this may be too low.

Is there a way to increase my efficeincy with GUI miner? I know it is recommended to use pheonix but I currently do not have the time or sufficient knowledge to setup this up. I know the information is out there to do it but my keyboard doesn't have a working forward slash key at the moment which makes command lines impossible. I could probably tie it to another key in some way but I dont know how. To find out just further adds to the time issue.

I will eventually move to pheonix as it seems to produce better figures but for now I need to make do with GUI miner.
member
Activity: 112
Merit: 10
May 14, 2011, 09:14:51 PM
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.

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

Thank you, thats what I've been trying to say all morning Cheesy
sr. member
Activity: 406
Merit: 250
May 14, 2011, 08:51:01 PM
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.

Quote
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.
member
Activity: 112
Merit: 10
May 14, 2011, 06:53:19 PM

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.
sr. member
Activity: 392
Merit: 250
May 14, 2011, 06:46:47 PM
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.
legendary
Activity: 1330
Merit: 1000
May 14, 2011, 06:40:42 PM
And... explain to me how turning away free workers makes "every block count"?

Perhaps their network connection is limited.
member
Activity: 112
Merit: 10
May 14, 2011, 06:18:55 PM

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"?
Pages:
Jump to: