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

CryptikEnigma

full member

Activity: 336

Merit: 101

Quote from: geebus on March 23, 2011, 08:31:44 PM

Quote from: CryptikEnigma on March 23, 2011, 08:22:27 PM

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

Thanks for the quick response

geebus

sr. member

Activity: 258

Merit: 250

Quote from: [Tycho] on March 23, 2011, 08:40:03 PM

Quote from: geebus on March 23, 2011, 08:31:44 PM

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.

Cool, thanks for the info. Like I said, I don't pay too much attention to how long the confirmation takes. Wink

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: geebus on March 23, 2011, 08:31:44 PM

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.

geebus

sr. member

Activity: 258

Merit: 250

Quote from: CryptikEnigma on March 23, 2011, 08:22:27 PM

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

CryptikEnigma

full member

Activity: 336

Merit: 101

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?

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: xenon481 on March 23, 2011, 07:07:05 PM

Quote from: geebus on March 23, 2011, 05:58:46 PM

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.

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: geebus on March 23, 2011, 05:58:46 PM

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.

geebus

sr. member

Activity: 258

Merit: 250

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.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: slush on March 23, 2011, 11:00:35 AM

Quote from: FairUser on March 23, 2011, 09:11:42 AM

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: FairUser on March 23, 2011, 09:11:42 AM

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

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: FairUser on March 23, 2011, 09:11:42 AM

Quote from: slush on March 23, 2011, 07:47:36 AM

Quote from: FairUser on March 23, 2011, 07:36:43 AM

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.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: slush on March 23, 2011, 07:47:36 AM

Quote from: FairUser on March 23, 2011, 07:36:43 AM

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: xenon481 on March 23, 2011, 08:17:37 AM

Quoting the currently posted image for history.

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

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: FairUser on March 23, 2011, 02:07:58 AM

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

legendary

Activity: 1386

Merit: 1097

Quote from: FairUser on March 23, 2011, 07:36:43 AM

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.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: slush on March 23, 2011, 04:41:55 AM

Quote from: FairUser on March 23, 2011, 02:07:58 AM

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.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: Grinder on March 23, 2011, 04:31:43 AM

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: FairUser on March 23, 2011, 02:07:58 AM

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.

Grinder

legendary

Activity: 1284

Merit: 1001

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.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

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.

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