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

[xenon481]

If your efficiency is lower than 1% at the end of a round, you will be flagged as inefficient and temporarily banned for 20 minutes while the user hopefully attempts to fix the problem.  If this is a problem for you, please update your miner to our modified version of m0mchill's miner that is MUCH more efficient.

Pardon me if this is a stupid question, but I assume that the required efficience excludes CPU miners, is that correct?

Cheers,

I believe so (effectively), from what I've read so far. But not due to efficiency; instead, due to Stales.

- Anti-fraud protection.  We only accept shares from the current block, in the current round.

Stale Rate is dependent upon two variables; Ask Rate and the entire network's Block Solution Rate.

The longer that a Miner goes without doing a GetWork, the more often that it will be working on something that is no longer valid because the proper solution has already been found. The more often that the network solves blocks, the more often that this situation occurs.

By asking a CPU Miner (or any miner that isn't at least some X% of the network's total power) to process the entire getwork solution space before performing another GetWork, you are dooming that Miner to a very significant percentage of Stale shares.

In this sense it is favoring people with faster cards right?

Yes.

[1714309805]

1714309805

[geebus]

So your argument is purely based on the irrational emotions of the miner as opposed to mathematical certainty of the statistics.

We operate a pool. We don't charge for it, and we're providing a service to users... So yes, it' about "irrational emotions".

The theory behind a score based system assumes that you're continuously mining, and continuously submitting shares at roughly the same average speed (give or take some variance) in order for it to be fair, after an extended period of time... and it is. I'm not questioning that.

However, in order for it to be fair for all miners, casual or hardcore, continuous or sporadic, you have to make each share retain it's value for the full duration of the round.

Pay-per-share is also an entirely valid method, but it's a gamble on the part of the server administrator.

So, to break it down:

1) Score based - Fair over time for continuous users, more beneficial immediately for faster GPUs vs slower CPUs, less risk of exploitation
2) Share based - Fair for all users immediately, CPU or GPU. Possible risk of exploitation if not protected against.
3) Pay-per-share - Fair for all users, but poses a potential risk to the pool operator in regard to loss.

Each is fair, with it's own benefits and concerns. We chose #2 in this case. If you don't like it, go somewhere else that suits your needs/wants/desires more.

[kseistrup]

Pardon me if this is a stupid question, but I assume that the required efficiency excludes CPU miners, is that correct?

I believe so (effectively), from what I've read so far. But not due to efficiency; instead, due to Stales.

That makes sense, thanks for making it obvious.

Someone should start a CPU-only mining pool. 

Cheers,

[[Tycho]]

Pardon me if this is a stupid question, but I assume that the required efficiency excludes CPU miners, is that correct?

I believe so (effectively), from what I've read so far. But not due to efficiency; instead, due to Stales.

That makes sense, thanks for making it obvious.
Someone should start a CPU-only mining pool.  ;)

There is no need for this. CPU miners can work fine with usual pool and get MORE reward than from special CPU-only pool.

[xenon481]

The theory behind a score based system assumes that you're continuously mining, and continuously submitting shares at roughly the same average speed (give or take some variance) in order for it to be fair, after an extended period of time... and it is. I'm not questioning that.

Just to clarify,

It has nothing to do with continuously working. The difference in variance tightly converges with the number of shares submitted throughout the entire lifetime of the Miner, completely regardless of how often those shares are submitted. You could have it running only a few hours a day, and the variance difference will still converge at the same rate per share.

[geebus]

By asking a CPU Miner (or any miner that isn't at least some X% of the network's total power) to process the entire getwork solution space before performing another GetWork, you are dooming that Miner to a very significant percentage of Stale shares.

Potentially stale to the network, yes... to the pool, not always.

To that degree though, you could technically say that any miner who has not solved a block for the pool is not benefiting the pool. We tend to disagree, and thats why we credit equally across the board. A submitted share is a submitted share.

The point of efficiency in mining is to reduce server load, thus allowing a much larger number of users to participate in the pool, so if one user is requesting only 1/10th the number of getworks as another, but submitting the same number of shares, I'd say they're doing us, and everyone in the pool a service by allowing us to accept more users.

Thats our perspective though. It works for us, and you're open to your own opinions.

I apologize if some of these answers make little sense. It's now 6AM for me and I'm heading to bed in order to get some much needed sleep. The past two weeks has been an average of 10 hours of coding, a full time job, and 4 - 5 hours of sleep per night.

[geebus]

Pardon me if this is a stupid question, but I assume that the required efficiency excludes CPU miners, is that correct?

I believe so (effectively), from what I've read so far. But not due to efficiency; instead, due to Stales.

That makes sense, thanks for making it obvious.

Someone should start a CPU-only mining pool. 

Cheers,

We've got something in the works specifically for CPU miners. We'll keep you posted.

[kseistrup]

Someone should start a CPU-only mining pool. 

There is no need for this. CPU miners can work fine with usual pool and get MORE reward than from special CPU-only pool.

I was partly joking… 

I guess I'll just stay in slush's pool.  I get a very, very small — but steady — amount of BTC every few days.

Cheers,

[nster]

So payment is every time a block is solved? we can't make an auto-payment thing so that we get payed, say, for every 5BTC or something?

[xenon481]

By asking a CPU Miner (or any miner that isn't at least some X% of the network's total power) to process the entire getwork solution space before performing another GetWork, you are dooming that Miner to a very significant percentage of Stale shares.

Potentially stale to the network, yes... to the pool, not always.

To that degree though, you could technically say that any miner who has not solved a block for the pool is not benefiting the pool. We tend to disagree, and thats why we credit equally across the board. A submitted share is a submitted share.

That's not what the OP says:

- Anti-fraud protection.  We only accept shares from the current block, in the current round.

FairUser said that submitted shares are only accepted from the current block within the current round.

If you want to change this to just within the current round (what you are implying), then the Solution Rate variable for the Stale Rate computation would be based on the Pool's Solution Rate as opposed to the Network's Solution Rate.

[geebus]

So payment is every time a block is solved? we can't make an auto-payment thing so that we get payed, say, for every 5BTC or something?

You will be able to eventually, as this is currently beta and we're still adding in new features, but presently, as stated in the FAQ, it pays every time a block is confirmed.

[batfink]

uh, quick question...

I seem to have more than 100% efficency with more jobs submitted than requested...

Is this normal?

Getwork Efficiency -
# Requested:    96
# Submitted:    104
Efficiency:    108%

[xenon481]

uh, quick question...

I seem to have more than 100% efficency with more jobs submitted than requested...

Is this normal?

Getwork Efficiency -
# Requested:    96
# Submitted:    104
Efficiency:    108%

From what I understand of their system, yes. Each GetWork solution space can contain more than one (or even 0) possible solution. As such, you have submitted 104 solutions from 96 GetWork calls.

[nster]

uh, quick question...

I seem to have more than 100% efficency with more jobs submitted than requested...

Is this normal?

Getwork Efficiency -
# Requested:    96
# Submitted:    104
Efficiency:    108%

very normal

[nster]

everytime I refresh to see how many BTC I should have, it lowers, why is that?

Holy f%^#% I just made myself lose like 0.01 BTC...

[kseistrup]

If people with CPU miners are unsure if they should join this pool — i.e., if they can live up to 1% efficiency — here are some numbers from the fastest of my CPU miners (and you will see it's pretty slow):

I'm running jgarzik's cpuminer single-threaded with the sse2_64 algorithm on a Core2Duo E6550 @ 2.33 GHz and a scantime of 7 seconds, which gives it a speed of 2,452 ± 272 khash/s (p=.95, based on 56,533 getworks).

Now, out of those 56,533 getworks the miner has delivered 224 POWs.  Ladies and gentlemen, that's a whopping efficiency of 0.396% (and so this miner doesn't qualify)!

That said, I do like the share-based payout system…

Cheers,

[grue]

is it possible for you to implement a SSE2 based miner? the current miner you have does not use SSE2, and its running at half the speed, compared to SSE2 miner.

[nster]

is it possible for you to implement a SSE2 based miner? the current miner you have does not use SSE2, and its running at half the speed, compared to SSE2 miner.

perhaps current SSE2 miners are compatible with his pool?

[grue]

is it possible for you to implement a SSE2 based miner? the current miner you have does not use SSE2, and its running at half the speed, compared to SSE2 miner.

perhaps current SSE2 miners are compatible with his pool?

can you show me one that works? the one im using that gets "the connection with the server was reset"

[nster]

is it possible for you to implement a SSE2 based miner? the current miner you have does not use SSE2, and its running at half the speed, compared to SSE2 miner.

perhaps current SSE2 miners are compatible with his pool?

can you show me one that works? the one im using that gets "the connection with the server was reset"

Have you tried ufasoft? It could be that it doesn't work, but if a CPU miner works with this pool, most likely ufasoft's will work