Bitcoin Forum
December 09, 2016, 07:25:56 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
Author Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)  (Read 96069 times)
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 08, 2011, 01:58:42 PM
 #21

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.

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

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
1481311556
Hero Member
*
Offline Offline

Posts: 1481311556

View Profile Personal Message (Offline)

Ignore
1481311556
Reply with quote  #2

1481311556
Report to moderator
1481311556
Hero Member
*
Offline Offline

Posts: 1481311556

View Profile Personal Message (Offline)

Ignore
1481311556
Reply with quote  #2

1481311556
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481311556
Hero Member
*
Offline Offline

Posts: 1481311556

View Profile Personal Message (Offline)

Ignore
1481311556
Reply with quote  #2

1481311556
Report to moderator
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 08, 2011, 02:02:13 PM
 #22

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
kseistrup
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
March 08, 2011, 02:03:46 PM
 #23

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,

Klaus Alexander Seistrup
http://about.me/kseistrup
[Tycho]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
March 08, 2011, 02:05:31 PM
 #24

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.

Welcome to my bitcoin mining pool: https://deepbit.net - Both payment schemes (including PPS), instant payout, no invalid blocks !
ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures (NEW!). Third year in bitcoin business.
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 08, 2011, 02:10:33 PM
 #25

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 08, 2011, 02:11:12 PM
 #26

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 08, 2011, 02:12:26 PM
 #27

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
kseistrup
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
March 08, 2011, 02:12:38 PM
 #28

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,

Klaus Alexander Seistrup
http://about.me/kseistrup
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 08, 2011, 02:14:00 PM
 #29

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?

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 08, 2011, 02:24:33 PM
 #30

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 08, 2011, 02:26:48 PM
 #31

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
batfink
Newbie
*
Offline Offline

Activity: 3


Just a random name :)


View Profile
March 08, 2011, 04:59:42 PM
 #32

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%
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 08, 2011, 05:02:38 PM
 #33

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 08, 2011, 05:17:31 PM
 #34

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

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 08, 2011, 09:22:58 PM
 #35

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

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
kseistrup
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
March 08, 2011, 10:14:20 PM
 #36

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,

Klaus Alexander Seistrup
http://about.me/kseistrup
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
March 08, 2011, 11:20:40 PM
 #37

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.

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 08, 2011, 11:22:14 PM
 #38

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?

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
March 08, 2011, 11:49:33 PM
 #39

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"

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 09, 2011, 12:10:14 AM
 #40

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

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!