Bitcoin Forum
December 03, 2016, 10:05:50 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 95980 times)
demonofelru
Full Member
***
Offline Offline

Activity: 238



View Profile
March 23, 2011, 04:39:09 AM
 #381

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

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

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.

Names do not matter; however, if you insist...id...
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
March 23, 2011, 05:10:42 AM
 #382

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

Activity: 261


View Profile WWW
March 23, 2011, 07:07:58 AM
 #383

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
Legendary
*
Offline Offline

Activity: 1269


View Profile
March 23, 2011, 09:31:43 AM
 #384

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
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 23, 2011, 09:41:55 AM
 #385

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

Activity: 261


View Profile WWW
March 23, 2011, 10:34:01 AM
 #386

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

Activity: 261


View Profile WWW
March 23, 2011, 12:36:43 PM
 #387

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
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 23, 2011, 12:47:36 PM
 #388

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

Activity: 406



View Profile
March 23, 2011, 01:17:37 PM
 #389

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 23, 2011, 01:48:04 PM
 #390

Quoting the currently posted image for history.

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

FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
March 23, 2011, 02:11:42 PM
 #391

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]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
March 23, 2011, 03:37:28 PM
 #392

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.

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.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 23, 2011, 04:00:35 PM
 #393

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

Activity: 261


View Profile WWW
March 23, 2011, 04:26:21 PM
 #394

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

Activity: 258



View Profile WWW
March 23, 2011, 10:58:46 PM
 #395

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.

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

Activity: 406



View Profile
March 24, 2011, 12:07:05 AM
 #396

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.

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

Activity: 261


View Profile WWW
March 24, 2011, 12:46:06 AM
 #397

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
Full Member
***
Offline Offline

Activity: 140



View Profile
March 24, 2011, 01:22:27 AM
 #398

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 Smiley


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

Activity: 258



View Profile WWW
March 24, 2011, 01:31:44 AM
 #399

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 Smiley


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

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
[Tycho]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
March 24, 2011, 01:40:03 AM
 #400

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.

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