Pages:
Author

Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :) - page 37. (Read 101960 times)

sr. member
Activity: 1344
Merit: 264
bit.ly/3QXp3oh | Ultimate Launchpad on TON
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... Cry

That is happening because other people in that time between refreshes have submitted their shares...which increases their earnings and subsequently decreases your by a small amount.
Likewise, you will notice that right after you submit a share, your earnings will have increased by a little bit.
full member
Activity: 126
Merit: 100
I think I got banned from bitcoinpool.com (and the miner does work either) because I refreshed the page too many times

Could you unban me please  Embarrassed
full member
Activity: 126
Merit: 100
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
legendary
Activity: 2058
Merit: 1462
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"
full member
Activity: 126
Merit: 100
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?
legendary
Activity: 2058
Merit: 1462
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.
hero member
Activity: 566
Merit: 500
Unselfish actions pay back better
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,
full member
Activity: 126
Merit: 100
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... Cry
full member
Activity: 126
Merit: 100
uh, quick question...

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

Is this normal?

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

very normal
sr. member
Activity: 406
Merit: 250
uh, quick question...

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

Is this normal?

Quote
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.
newbie
Activity: 3
Merit: 0
uh, quick question...

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

Is this normal?

Quote
Getwork Efficiency -
# Requested:    96
# Submitted:    104
Efficiency:    108%
sr. member
Activity: 258
Merit: 250
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.
sr. member
Activity: 406
Merit: 250
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:

Quote
- 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.
full member
Activity: 126
Merit: 100
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?
hero member
Activity: 566
Merit: 500
Unselfish actions pay back better
Someone should start a CPU-only mining pool.  Wink
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…  Smiley

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,
sr. member
Activity: 258
Merit: 250
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.  Wink

Cheers,

We've got something in the works specifically for CPU miners. We'll keep you posted.
sr. member
Activity: 258
Merit: 250
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.
sr. member
Activity: 406
Merit: 250
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.
hero member
Activity: 742
Merit: 500
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.
hero member
Activity: 566
Merit: 500
Unselfish actions pay back better
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.  Wink

Cheers,
Pages:
Jump to: