Bitcoin Forum
December 02, 2016, 06:34:49 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3160 (80.5%)
Bank transfer / USD - 407 (10.4%)
Gold/silver coins and bars - 359 (9.1%)
Total Voters: 3924

Pages: « 1 ... 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 [471] 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 ... 1105 »
  Print  
Author Topic: [40+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 3924744 times)
iFA88
Full Member
***
Offline Offline

Activity: 218



View Profile WWW
June 02, 2013, 10:03:14 AM
 #9401

So when the duration is on 1:00:00 then we reset the Total Score variable (we dont reset the user score variable!) and we set the "spin" to 1
on 2:00:00 we reseting again, and set the spin to 2
on 3:00:00 to 3 and so follow..
and when the block founded, then we calculate from these method:
reward = ( user score / spin ) / total score * 25
All is done?!

This will lead to wrong results: on spin 1 the total score is 1234567890, but on next spin it is 1934567890 - they are never equal
How are u calculated this? On the spin increment the total score reset it to 0.
1480703689
Hero Member
*
Offline Offline

Posts: 1480703689

View Profile Personal Message (Offline)

Ignore
1480703689
Reply with quote  #2

1480703689
Report to moderator
1480703689
Hero Member
*
Offline Offline

Posts: 1480703689

View Profile Personal Message (Offline)

Ignore
1480703689
Reply with quote  #2

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

Posts: 1480703689

View Profile Personal Message (Offline)

Ignore
1480703689
Reply with quote  #2

1480703689
Report to moderator
KNK
Hero Member
*****
Offline Offline

Activity: 615


View Profile
June 02, 2013, 10:06:00 AM
 #9402

I mean just before it is reset, because it based on time and not some value it will always be different, so ... wrong end results
The numbers are just for example

BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
iFA88
Full Member
***
Offline Offline

Activity: 218



View Profile WWW
June 02, 2013, 10:10:21 AM
 #9403

I mean just before it is reset, because it based on time and not some value it will always be different, so ... wrong end results
The numbers are just for example
score = score + exp(round_time/C)
The result is only a number ^^
With these method, when the round time too long is, then the value would overflow.
KNK
Hero Member
*****
Offline Offline

Activity: 615


View Profile
June 02, 2013, 10:22:59 AM
 #9404

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalk.org/index.php?topic=1976.msg2330839#msg2330839

BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
June 02, 2013, 10:29:37 AM
 #9405

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
iFA88
Full Member
***
Offline Offline

Activity: 218



View Profile WWW
June 02, 2013, 10:35:49 AM
 #9406

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalk.org/index.php?topic=1976.msg2330839#msg2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
June 02, 2013, 10:45:57 AM
 #9407

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalk.org/index.php?topic=1976.msg2330839#msg2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

Perhaps you missed this:

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Or maybe you didn't understand?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
iFA88
Full Member
***
Offline Offline

Activity: 218



View Profile WWW
June 02, 2013, 10:59:58 AM
 #9408

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalk.org/index.php?topic=1976.msg2330839#msg2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

Perhaps you missed this:

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Or maybe you didn't understand?
Then, i think i dont understand.
For me says reset thah reseting scores to zero.
CJPOLO
Jr. Member
*
Offline Offline

Activity: 34


View Profile
June 02, 2013, 11:13:43 AM
 #9409

Slush any news on blocks
18309 and 18318 in regards to miscalculations?
thanks
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
June 02, 2013, 11:29:01 AM
 #9410

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalk.org/index.php?topic=1976.msg2330839#msg2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

Perhaps you missed this:

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Or maybe you didn't understand?
Then, i think i dont understand.
For me says reset thah reseting scores to zero.

OK, then reset your idea about "reset" : it just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Let hear no more about it, eh?



Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
vs3
Hero Member
*****
Offline Offline

Activity: 622


View Profile WWW
June 02, 2013, 12:07:20 PM
 #9411

To be quite honest - I'm not sure why is there the need of "reset" in the first place? I mean - why set it to zero? Why not just set it to half of what it is - that way the proportional part for everyone would stay the same (e.g. each miner's contribution % would not change)?


p.s. someone suggested earlier that it is a double-integer - that's probably wrong as it seems to be a floating point type (most likely whatever the default python/php one is)

diskodasa
Member
**
Offline Offline

Activity: 84


BTC 1Hek4mF4sHcpEJpQdeKwN2i1rVrK5JcZuy


View Profile
June 02, 2013, 12:15:19 PM
 #9412

Now what!!!???
18329    2013-06-02 01:07:40    0:20:23    3210872    334    0.00273237    239177    25.14480000    invalid

1Hek4mF4sHcpEJpQdeKwN2i1rVrK5JcZuy
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
June 02, 2013, 12:15:26 PM
 #9413

To be quite honest - I'm not sure why is there the need of "reset" in the first place? I mean - why set it to zero? Why not just set it to half of what it is - that way the proportional part for everyone would stay the same (e.g. each miner's contribution % would not change)?


p.s. someone suggested earlier that it is a double-integer - that's probably wrong as it seems to be a floating point type (most likely whatever the default python/php one is)


The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.


THERE IS NO "RESET TO ZERO".

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
TiborB
Member
**
Offline Offline

Activity: 83


View Profile
June 02, 2013, 12:21:24 PM
 #9414

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalk.org/index.php?topic=1976.msg2330839#msg2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

Perhaps you missed this:

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Or maybe you didn't understand?
Then, i think i dont understand.
For me says reset thah reseting scores to zero.

OK, then reset your idea about "reset" : it just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Let hear no more about it, eh?




OrganOfCorti,

I have read many of your writings and comments here and I am convinced you do know very well what you are talking about. However, with all respect I am not sure you are 100% right in this case. Yes, what you write is how it should work, but I wonder if you have seen and analysed the actual code performing the renormalization. What we know from experience is, that a round, that ended very closely after a renormalisation, yields rewards being off by magnitudes, which affects some miners in a positive, others in a negative way. It seems, the closer to a renormalisation the round ends, the larger the deviation from the expected avg reward.

My guess (which is only a guess based on observations) is that constant C in the formula is not changed after the renormalisation to match the scale-down factor of existing scores. If it was correctly changed, then a share submitted right after a renormalization would have the same impact/importance, than the share submitted right before the renormalization. This does not seem to be the case.

In really extreme cases, where the deviation is significant (e.g. only a few satoshis for continuous miners even at around 1Gh/s), Slush recalculates the blocks manually with PPS. You can see that after a "magical fix" that we see in some cases your score is equal to the number of shares you submitted. (I have been collecting and storing block stats for two months and am not just making this up.)

Please let me know if you think I made a logical mistake in my conclusions, I am always open to learn. And it also belongs to learning to periodically revisit and challenge previous theories and statements. So no offence is intended whatsoever.

Cheers,
   T




vs3
Hero Member
*****
Offline Offline

Activity: 622


View Profile WWW
June 02, 2013, 12:22:25 PM
 #9415

Now what!!!???
18329    2013-06-02 01:07:40    0:20:23    3210872    334    0.00273237    239177    25.14480000    invalid

This was already a known fact:

239177 orphaned.

Grr etc. oh well, at least it isn't because some flawed logic in an equation

DryMartini
Jr. Member
*
Offline Offline

Activity: 37



View Profile
June 02, 2013, 12:27:02 PM
 #9416

Honestly. The reset thingy is just another bug caused by arithmetic overflow. This pool is so full of bugs I'm not sure it can be called a pool any longer. It's something between Satoshi Dice, a daycare center and a mining pool.

Is it a bingo hall?
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
June 02, 2013, 12:35:00 PM
 #9417


OrganOfCorti,

I have read many of your writings and comments here and I am convinced you do know very well what you are talking about. However, with all respect I am not sure you are 100% right in this case.Yes, what you write is how it should work, but I wonder if you have seen and analysed the actual code performing the renormalization. What we know from experience is, that a round, that ended very closely after a renormalisation, yields rewards being off by magnitudes, which affects some miners in a positive, others in a negative way. It seems, the closer to a renormalisation the round ends, the larger the deviation from the expected avg reward.
No, no-one I know has audited slush's code. So any claims that the renormalisation is broken need to be proven - anecdotal evidence is insufficient. You'll need to prove your assertion beyond a doubt, not just show examples of when you think it misfires. ou could be correct - why not actually do the groundwork and prove it?

My guess (which is only a guess based on observations) is that constant C in the formula is not changed after the renormalisation to match the scale-down factor of existing scores.

If it was correctly changed, then a share submitted right after a renormalization would have the same impact/importance, than the share submitted right before the renormalization. This does not seem to be the case.

'c' should never be changed. If it did, the score method wouldn't work.

In really extreme cases, where the deviation is significant (e.g. only a few satoshis for continuous miners even at around 1Gh/s), Slush recalculates the blocks manually with PPS. You can see that after a "magical fix" that we see in some cases your score is equal to the number of shares you submitted. (I have been collecting and storing block stats for two months and am not just making this up.)

Please let me know if you think I made a logical mistake in my conclusions, I am always open to learn. And it also belongs to learning to periodically revisit and challenge previous theories and statements. So no offence is intended whatsoever.

Cheers,
   T

You think something's wrong - fair enough. But now you need to prove it. You'll need lots of data, and you'll have to scrape slush's site every few minutes. But it's doable.

Good luck!


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
KNK
Hero Member
*****
Offline Offline

Activity: 615


View Profile
June 02, 2013, 12:55:41 PM
 #9418

You'll need lots of data, and you'll have to scrape slush's site every few minutes. But it's doable.

Good luck!

You just don't read do you?
I have been collecting and storing block stats for two months and am not just making this up.

You are so sure in what you think that every one else is just wrong and your theory is better than the other's observations based on facts.
That's why i didn't want to argue with you few pages back and i won't even now.

BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
June 02, 2013, 12:58:30 PM
 #9419

You'll need lots of data, and you'll have to scrape slush's site every few minutes. But it's doable.

Good luck!

You just don't read do you?
I have been collecting and storing block stats for two months and am not just making this up.

You are so sure in what you think that every one else is just wrong and your theory is better than the other's observations based on facts.

TiborB hasn't produced a proof, just anecdotal evidence. He needs to show exactly what should have happened if a renormalisation rather than a "reset" occurred for his dataset.

That's why i didn't want to argue with you few pages back and i won't even now.

Good-oh!

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
TiborB
Member
**
Offline Offline

Activity: 83


View Profile
June 02, 2013, 01:27:15 PM
 #9420


OrganOfCorti,

I have read many of your writings and comments here and I am convinced you do know very well what you are talking about. However, with all respect I am not sure you are 100% right in this case.Yes, what you write is how it should work, but I wonder if you have seen and analysed the actual code performing the renormalization. What we know from experience is, that a round, that ended very closely after a renormalisation, yields rewards being off by magnitudes, which affects some miners in a positive, others in a negative way. It seems, the closer to a renormalisation the round ends, the larger the deviation from the expected avg reward.
No, no-one I know has audited slush's code. So any claims that the renormalisation is broken need to be proven - anecdotal evidence is insufficient. You'll need to prove your assertion beyond a doubt, not just show examples of when you think it misfires. ou could be correct - why not actually do the groundwork and prove it?

My guess (which is only a guess based on observations) is that constant C in the formula is not changed after the renormalisation to match the scale-down factor of existing scores.

If it was correctly changed, then a share submitted right after a renormalization would have the same impact/importance, than the share submitted right before the renormalization. This does not seem to be the case.

'c' should never be changed. If it did, the score method wouldn't work.

In really extreme cases, where the deviation is significant (e.g. only a few satoshis for continuous miners even at around 1Gh/s), Slush recalculates the blocks manually with PPS. You can see that after a "magical fix" that we see in some cases your score is equal to the number of shares you submitted. (I have been collecting and storing block stats for two months and am not just making this up.)

Please let me know if you think I made a logical mistake in my conclusions, I am always open to learn. And it also belongs to learning to periodically revisit and challenge previous theories and statements. So no offence is intended whatsoever.

Cheers,
   T

You think something's wrong - fair enough. But now you need to prove it. You'll need lots of data, and you'll have to scrape slush's site every few minutes. But it's doable.

Good luck!



Thanks for the response, you are absolutely right. I do pull the statistics via the JSON API every 10 minutes and analyse & plot it automatically every 6 hours. (I do not want to pull more frequently for practical reasons.)

At this point in time, based on stats from the last 2 months, what I see confirmed is the "magical fix" manual recalculation via PPS which is easy to spot and slush has been honest about it when I contacted him (he is very open and honest, and I do understand him not wanting to actively post here recently).

I do not think that based on my current amount of data I could back my assertion beyond a doubt, this is why I was very explicitly calling it a guess. I could collect data and perform "black box analysis" for any amount of time and still not reach 100% as it is theoretically impossible to reach 100% via passive black box analysis but the confidence level is growing with the amount of data collected.

Checking the code (aka white box analysis) could be much less effort taking and allow for a statement beyond doubt. And honestly, I have never even seen a precise description of what exactly is done on a renormalisation, only the fact is mentioned that a renormalisation is periodically performed. In contrast to this, Meni Rosenfeld is very explicit in how rescaling should work when using DGM (https://bitcointalk.org/index.php?topic=39497.0).

Regarding changes to C: what I mean is that on rescaling/renormalization, when the score is changed, but C is not, then you very aggressively change the weight of all the work one has performed before renormalisation versus the weight of the new per share increment. However, if the score is divided by X, and C multiplied by log(X), then the value of previous scores relative to the value of the increment score for the new share is kept the same (maintaining the exponential semantics used by slush), and you will end up with the same exponential curve, just rescaled (zoomed out).

Cheers,
   T
Pages: « 1 ... 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 [471] 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 ... 1105 »
  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!