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

[demonofelru]

I'm not sure why, but this pool seems to have lower earnings than slush's pool. after crunching some data from slush's pool, i found out that i make around 0.03 BTC per hour mining. However, i ran a miner for 1 entire day, and the "estimated earnings" is only 0.06 BTC.

Slush is taking BTC from the top when no one watches..... plus he has forced donations cause he a fucking douch! So there goes those earnings you just made.

This pool is prolly the most optimized from what I've seen. admins are pretty active too.

RTFM, search the forums. If you cant find yer answer, ask and I'm sure someone will chim in.

Do you have any evidence at all that Slush is acting deceitful or are you just assuming?  I honestly can understand being upset about the donation thing not that Slush charges a fee but that he originally said it was going away then said it wasn't but would only be 1%.  Be that as it may he obviously changed his mind and there are pools I could switch to if need be.  I think it is incredibly messed up accusing someone of fraud without backing it up though if you can show he is doing this please show me either in PM or a post here I might even throw some BTC your way if it's true.

[1714326999]

1714326999

[1714326999]

1714326999

[1714326999]

1714326999

[FairUser]

Wish this round was over
added a couple machines
I'll have to wait and see what that means
now its now down to can you keep up (do enough crunching) with added shares
..and added users
hope it gets done soon

It's down to you can, bobR, keep up with others in the pool.  The more you can crunch, the more you earn.
Yes, our server can handle it with no problems.

I would like the round to end soon too.

[FairUser]

Here is a good example of what Geebus and I are talking about.
This an example of 21,010 getworks that had the entire getwork processed.
You can find the full data set at: http://bitcoinpool.com/data/found-share-stats.html



We can see that there is plenty of shares found throughout the entire space of (2^32) possible hashes. 
So this begs the question, why do we even need an askrate when we have long polling now? 
Couldn't the miners just work through the entire getwork, and ask for more when they're done with what they had? 
The obvious exception is to stop working on what you got when a new getwork comes back down the long polling channel.


Edit:  Grinder just pointed out a flaw in the counting code and hence the stats were off.  Graph and stats updated. Thank you grinder.

[Grinder]

The client probably just doesn't calculate the percentage correctly, there are way more hits on even percentage numbers than odd. Also, you don't include 0 in your statistics, "0%" has 488 hits.

[slush]

Here is a good example of what Geebus and I are talking about.  

Did you noticed that graph shows significantly higher shares probability on every second nonce range? 8-12, 16-20 etc. Why not skip all those ranges with lower probability? You'll earn +1/4 results in the same crunching time. And of course filter out beginning of the range with the lowest probability.

[FairUser]

The client probably just doesn't calculate the percentage correctly, there are way more hits on even percentage numbers than odd. Also, you don't include 0 in your statistics, "0%" has 488 hits.

Thank you for pointing that out.  The counting code got mixed up when tallying the results.  Original post edited.

[FairUser]

Here is a good example of what Geebus and I are talking about.  

Did you noticed that graph shows significantly higher shares probability on every second nonce range? 8-12, 16-20 etc. Why not skip all those ranges with lower probability? You'll earn +1/4 results in the same crunching time. And of course filter out beginning of the range with the lowest possibility.

We need to get more logs from other users.

If those of you who are using our modified miner, could you please add the "--log" option to your command line and PM Geebus or myself when you get a few logs generated?  It would be helpful to get the most stats possible to see if this distribution evens out. 

Thank you.

[slush]

We need to get more logs from other users.

Afaik you can collect those stats directly on the server, in the same way as I'm doing it.

[xenon481]

Here is a good example of what Geebus and I are talking about.
This an example of 21,010 getworks that had the entire getwork processed.
You can find the full data set at: http://bitcoinpool.com/data/found-share-stats.html



We can see that there is plenty of shares found throughout the entire space of (2^32) possible hashes. 
So this begs the question, why do we even need an askrate when we have long polling now? 
Couldn't the miners just work through the entire getwork, and ask for more when they're done with what they had? 
The obvious exception is to stop working on what you got when a new getwork comes back down the long polling channel.


Edit:  Grinder just pointed out a flaw in the counting code and hence the stats were off.  Graph and stats updated. Thank you grinder.

Quoting the currently posted image for history.

[slush]

Quoting the currently posted image for history.

Now it's finally clear that miners should skip 20-24% from each getwork.

[FairUser]

We need to get more logs from other users.

Afaik you can collect those stats directly on the server, in the same way as I'm doing it.

I would like to know how a pool operator could track, from server side, at what percent of the getwork the share was found at.  I don't think that's possible.  This is why we log it on the client side in a log file though.

If you figure that out, let me know.

[[Tycho]]

We need to get more logs from other users.

Afaik you can collect those stats directly on the server, in the same way as I'm doing it.

I would like to know how a pool operator could track, from server side, at what percent of the getwork the share was found at.  I don't think that's possible.  This is why we log it on the client side in a log file though.

I really hope that you are joking.

Otherwise you should read bitcoin wiki or ask the guy that created your pool software.

[slush]

I would like to know how a pool operator could track, from server side, at what percent of the getwork the share was found at.  I don't think that's possible.  This is why we log it on the client side in a log file though.

FairUser, I really hope you're just making fun from us. When you see nonce in the Block Explorer for every block you found, there _must_ be some way how to check this on the pool, because you own full block source.

Hint: Check data string submitted from the miner to the pool, especially find the difference between two shares found from the same job. I'm sure you'll find what you need...

[FairUser]

I would like to know how a pool operator could track, from server side, at what percent of the getwork the share was found at.  I don't think that's possible.  This is why we log it on the client side in a log file though.

FairUser, I really hope you're just making fun from us. When you see nonce in the Block Explorer for every block you found, there _must_ be some way how to check this on the pool, because you own full block source.

Hint: Check data string submitted from the miner to the pool, especially find the difference between two shares found from the same job. I'm sure you'll find what you need...

Did neither of you read what I said?

Let me put it another way so maybe you'll understand what I'm asking.

When a share is submitted, how can the pool server know the percentage that the share was found at in the getwork?  
Was it found at 4%, 32% or 100% in the getwork??  
AFAIK, that information is not sent to the server.
 
I'm not asking about the nonce, cause yes, I can see that.
I'm asking the about the percentage where the nonce was found at inside it's getwork.
Is that being tracked, if so, where?  

I don't believe this percentage is being tracked by the server at all, but if I'm wrong, please explain where in the share the percentage, not the nonce, is listed.

[geebus]

I'd be curious as well, to know exactly how you can determine at what point in the getwork that the share was found. As far as I can tell, there isn't a way for me to determine at what point in the getwork that a miner found an answer, from the server side.

[xenon481]

I'd be curious as well, to know exactly how you can determine at what point in the getwork that the share was found. As far as I can tell, there isn't a way for me to determine at what point in the getwork that a miner found an answer, from the server side.

I haven't looked at the python pool code you used as a base, but I think that you should be able to infer that information from the nonce number in share returned to the pool when the pool validates the share. This should be inferrable as the miner just increments the nonce counter (keeping in mind extraNonce) as it processes through the hash space.

[FairUser]

I'd be curious as well, to know exactly how you can determine at what point in the getwork that the share was found. As far as I can tell, there isn't a way for me to determine at what point in the getwork that a miner found an answer, from the server side.

I haven't looked at the python pool code you used as a base, but I think that you should be able to infer that information from the nonce number in share returned to the pool when the pool validates the share. This should be inferrable as the miner just increments the nonce counter (keeping in mind extraNonce) as it processes through the hash space.

I thought about that, but it doesn't look like the nonce start at 0x00000000 and working sequentially towards 0xFFFFFFFF based on the results from miner logs.  If it was sequential then this would be a lot easier to figure out server side.  I haven't looking at the BitcoinMiner.cl in depth, so I do not know how it is picking it's nonces.  I guess if we could predict how the BitcoinMiner.cl kernel generates nonces, then maybe we could figure out the percentage of getwork the nonce was found at.

I suspect further investigating will tell.

[CryptikEnigma]

I signed up for this pool, and also got a couple people from another forum I visit to sign up too. This seems to be one of the more open and honest pools around


I was wondering, I can see in my estimated earnings .02, but how long until that actually gets transferred to my bitcoin client, is it like once a week or something?

[geebus]

I signed up for this pool, and also got a couple people from another forum I visit to sign up too. This seems to be one of the more open and honest pools around


I was wondering, I can see in my estimated earnings .02, but how long until that actually gets transferred to my bitcoin client, is it like once a week or something?

Your estimated earnings is a 'best guess' of what you WILL earn when the block is solved by the pool (fairly random, but based on pool speed) based on the number of shares you've submitted vs the total number submitted by the pool.

Once the block is solved by the pool, it must mature. In order for that to happen, 120 blocks must be solved by the bitcoin network. Presently, that takes around 10 - 12 hours I think (honestly, I don't pay attention too much).

Once the block matures, you'll be paid the next time our payment system makes a check (happens once per minute).

Thanks for the support! We appreciate it...

[[Tycho]]

Once the block is solved by the pool, it must mature. In order for that to happen, 120 blocks must be solved by the bitcoin network. Presently, that takes around 10 - 12 hours I think (honestly, I don't pay attention too much).

Should be more than 20 hours at this time.