Bitcoin Forum
December 14, 2024, 01:10:05 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 [75] 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 ... 1154 »
  Print  
Author Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool  (Read 4382724 times)
cdhowie
Full Member
***
Offline Offline

Activity: 182
Merit: 107



View Profile WWW
March 26, 2011, 08:48:12 PM
 #1481

Every one can check in this site whether you have been sent coins or slush cheating you.
I can also check in my Bitcoin client.  I'm not sure what your point is.

I know you find it useful, & i am expecting donation from you.
I hope this is sarcasm.

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
LMGTFY
Hero Member
*****
Offline Offline

Activity: 644
Merit: 503



View Profile
March 26, 2011, 08:50:46 PM
 #1482

I hope this is sarcasm.
Humour. I think the curse at the end may have been the give-away...
Even after finding it helpful & refuse to donate me make you fart 100 times/ day. Its a curse, i secretly put with this message.

This space intentionally left blank.
dishwara
Legendary
*
Offline Offline

Activity: 1855
Merit: 1016



View Profile
March 26, 2011, 11:00:57 PM
 #1483

I think your pool shows wrong block in the stats page.
Current Bitcoin block#:   115201, but bitcoin client says 115201.
How can one mine a block which is already solved & accepted & showed by client?

I most times see that the current bitcoin block shows is always the one solved as per bitcoin client & many bitcoin sites.
Your statistic page never showed current REAL block which is mining currently.

I think its a small bug escaped.
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 26, 2011, 11:04:18 PM
 #1484

I think your pool shows wrong block in the stats page.
Current Bitcoin block#:   115201, but bitcoin client says 115201.
How can one mine a block which is already solved & accepted & showed by client?

I most times see that the current bitcoin block shows is always the one solved as per bitcoin client & many bitcoin sites.
Your statistic page never showed current REAL block which is mining currently.

I think its a small bug escaped.

No, the number is of course correct, I don't see any reason why it should differ from your client. This number mean how many blocks is currently in the blockchain, so it's perfectly fine that your client shows the same number.

Also don't forget that stats page is cached for 30 seconds, so when new block is found, the number on stats page can be different for few seconds.

dishwara
Legendary
*
Offline Offline

Activity: 1855
Merit: 1016



View Profile
March 26, 2011, 11:11:47 PM
 #1485



Is it possible?
May be i am wrong?
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 26, 2011, 11:25:43 PM
 #1486

Is it possible?
May be i am wrong?

*tired* I explained this many times. Again, yes this number is wrong, it is due to latency on bitcoin network, this does not affect anything, link to block explorer is correct.

Next?

P.S. Pleae don't double post (here and in fairuser's thread), not funny to respond you twice.

xenon481
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250



View Profile
March 26, 2011, 11:27:55 PM
 #1487

Is it possible?
May be i am wrong?

*tired* I explained this many times. Again, yes this number is wrong, it is due to latency on bitcoin network, this does not affect anything, link to block explorer is correct.

Next?

P.S. Pleae don't double post (here and in fairuser's thread), not funny to respond you twice.

In this particular case, that link to BlockExplorer shows that the 2nd block doesn't exist at all. I suspect it has something to do with the fact that it was found only 21 seconds after the previous one.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 26, 2011, 11:31:32 PM
 #1488

In this particular case, that link to BlockExplorer shows that the 2nd block doesn't exist at all. I suspect it has something to do with the fact that it was found only 21 seconds after the previous one.

Good catch, this block is invalid (damn Smiley ). I'm checking his presence in blockchain after 100 confirmations, so it will turn to 'invalid' then.

dacoinminster
Legendary
*
Offline Offline

Activity: 1260
Merit: 1031


Rational Exuberance


View Profile WWW
March 28, 2011, 08:50:22 PM
 #1489

I realized something this morning: The average number of shares per block should be close to the current difficulty

Perhaps you all knew this, but it was big news to me. The number of shares per block bounces around a ton, but if you average it over a long enough time period, it should be close to the current difficulty.

Once I came to this stunning realization, I was able to make this graph using data from here: http://mining.bitcoin.cz/stats/?history=1000

Check it out:



My original question to myself was: why the heck is the pool solving blocks as if difficulty was ~80000 instead of difficulty ~69000??

Now I have my answer (we appear to be victims of probability), and I thought I would share it with you guys.

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3920
Merit: 2349


Eadem mutata resurgo


View Profile
March 28, 2011, 10:28:22 PM
 #1490

dacoinmaster: Good spotting.

By the same reasoning then, the average shares per block should spend as much time below current difficulty as above current difficulty, (unless there are some rogue shares diluting the pool). It is an area under the curve thing, yes?

Thor
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile
March 28, 2011, 10:58:47 PM
 #1491

By my estimation, the average should actually be above the current difficulty.

If the range of the possible number of shares is from 1 - infinity  (if the transactions being worked on continue changing over time, then it could be infinite, it is VERY remotely possible for there to be a block that is never solved)

and the current difficulty is only: 68978.8924579

Many more blocks will take longer than the "expected" amount of time, which is simply an estimated amount of time to represent the group as a whole having spent enough time to generate a single full difficulty block.  Each hash you calculate has an equal chance of being the right one, form the very first, to the last one you allow your computer to check they all have an equal chance of being the lucky one.  It taking a long time to solve a block does not actually mean that we are necessarily any closer to solving one.  Therefore, with the likelihood of extreme outliers in any data with a large enough sample, the average time will end up being higher than the difficulty as a result of a few extreme cases.

I'm sure there are several miner [sic] mistakes in there, but the concept is reasonably accurate I think.

Also:  I like puns.
Miner-TE
Hero Member
*****
Offline Offline

Activity: 499
Merit: 500



View Profile
March 29, 2011, 05:06:39 AM
 #1492

Wish I had gotten a piece of this block ... Sad

2538    2011-03-28 21:57:49    0:00:02    8    none    115552    99 left

edit: Block number off or invalid. I'm feeling a little better.

BTC - 1PeMMYGn7xbZjUYeaWe9ct1VV6szLS1vkD - LTC - LbtcJRJJQQBjZuHr6Wm7vtB9RnnWtRNYpq
rikur
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
March 29, 2011, 06:09:21 AM
 #1493

#            Block found                    Duration    Total shares     Your Reward         Block        #   Validity
2538   2011-03-29   04:57:49  0:00:02   8    8                       none                       115552       93 confirmations left

Now that doesn't seem too fair. How could this be "fixed" to be more fair with the score based system? Maybe total shares < 1000, use the ratio from the last round?

EDIT: Ah. so it was a glitch/cheat attempt? Smiley
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 29, 2011, 08:42:39 AM
Last edit: March 29, 2011, 08:57:57 AM by slush
 #1494

#            Block found                    Duration    Total shares     Your Reward         Block        #   Validity
2538   2011-03-29   04:57:49  0:00:02   8    8                       none                       115552       93 confirmations left

Now that doesn't seem too fair. How could this be "fixed" to be more fair with the score based system? Maybe total shares < 1000, use the ratio from the last round?

Firstly, the block is invalid - the block redistribution is fairly slow and I'm being upset with it. Thinking about next bitcoin patch, we will see...

Next, why anybody who didn't contributed to the round should receive any reward? Smiley

slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 29, 2011, 08:44:09 AM
 #1495

I realized something this morning: The average number of shares per block should be close to the current difficulty

You're right, average round should have the same number of shares as current difficulty is. The graph you did shows the real variance in round durations.

rikur
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
March 29, 2011, 11:10:32 AM
 #1496

Next, why anybody who didn't contributed to the round should receive any reward? Smiley

Would be a lot more fair that way. CPU miners will never find a single share before the total share count is near 5k shares or so. In these cases, you could use the share ratio of the last round the did have time to actually find some shares for.

The idea is not fully finished yet.. But I guess you get the point. If the block was not invalid, only one or two guys would have gotten rewards even if everyone started to hash for it.
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 29, 2011, 07:12:46 PM
 #1497

CPU miners will never find a single share before the total share count is near 5k shares or so.

Why? This is not correct - everybody has the same chance to hit first share, of course proportionally to his hashrate. Just for curiosity, 7/8 shares was submitted by normal users with decent GPUs (I know some of the users so I can tell), not by users with strong rigs. Of course probability that CPU user with 1mhash/s hit one of first 8 shares is very low, but don't forget that he has 200-300x slower worker.

Quote
In these cases, you could use the share ratio of the last round the did have time to actually find some shares for.

Sorry, I still don't see why. And why the limit should be 5k shares and not 3k or 10k shares. Don't confuse fairness and luck; this artifical limit is definitely less _fair_, because it favors unlucky workers.

dishwara
Legendary
*
Offline Offline

Activity: 1855
Merit: 1016



View Profile
March 29, 2011, 08:18:52 PM
 #1498

I saw today this for more than an hour before i go to sleep

Approx. cluster performance:    159.736 Ghash/s
Avg. cluster performance:    2.701 Ghash/s
Avg. network performance:    10.130 Ghash/s

What happened? Network down or some thing?
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
March 29, 2011, 08:29:01 PM
Last edit: March 29, 2011, 11:46:26 PM by slush
 #1499

What happened? Network down or some thing?

No, everything is OK. The hashmeter is calculated from current round (is calculated from submitted shares/round duration). This means that after refresh instantly after block is found, you'll see "Cluster performance: 0Ghash/s", because there isn't any share yet. As the round is going, the hashmeter goes up to real cluster performance.

I have also implemented hashmeter with sliding 5min average (submitted shares in last 5min / 300 sec), which is currently not enabled. This hashmeter is not affected by round ends, but the hashrate variance is much bigger - 5min is not long enough window and speed is changing in +/- 20ghash/s.

EDIT: I just changed hashmeter from round-based to continuous and rised statistics window from 5min to 20min avg, so number should be much more steady/exact now.

rikur
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
March 30, 2011, 08:24:36 PM
 #1500

CPU miners will never find a single share before the total share count is near 5k shares or so.

Why? This is not correct - everybody has the same chance to hit first share, of course proportionally to his hashrate. Just for curiosity, 7/8 shares was submitted by normal users with decent GPUs (I know some of the users so I can tell), not by users with strong rigs. Of course probability that CPU user with 1mhash/s hit one of first 8 shares is very low, but don't forget that he has 200-300x slower worker.

Quote
In these cases, you could use the share ratio of the last round the did have time to actually find some shares for.

Sorry, I still don't see why. And why the limit should be 5k shares and not 3k or 10k shares. Don't confuse fairness and luck; this artifical limit is definitely less _fair_, because it favors unlucky workers.


Fair points, maybe the idea I threw wasn't quite up to the task. However, since I have endless supply of them ideas, here's another one:

What if the rewards would be calculated only once per day. Every user would get a reward of

total_btc_for_given_day * their_shares_for_given_day / total_shares_for_given_day

Would that make more sense? What other downsides would this have except slightly slower feed back on rewards for users? (altho you could still show a daily estimate).
Pages: « 1 ... 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 [75] 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 ... 1154 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!