Bitcoin Forum
March 29, 2024, 07:34:48 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Visual comparison of pool payout methods based on real-world data  (Read 9037 times)
HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 22, 2011, 10:27:43 PM
 #21

Regarding PPLNS:

interessting system. but it would just change hopping styles:
as i get it, u now join fresh rounds and leave when they take to long, and come back if a new one starts.
with pplns it's just the opposite. u join the long rounds, because they should be over soon and hopefully followed by shorter rounds, so u get paid triple and more. then leaving at the beginning of a new round in fear of a long round, where the first shares aren't worth anything. and being worth nothing should be a even stronger driving factor than being worth less.

I have no doubt that some people would think this way, but it offers no benefit to the hopper nor damage to the pool.

There is no such thing as 'this pool is due'. There is no way to tell, based on history, that a pool is going to hit more than average blocks soon. So there's no way to determine now is a better or worse time than average for participation in PPLNS.

To the extent people believe the 'something's-due' fallacy, it could be self-limiting. Superstitious people may pile into a pool that seems to have gone a long wall-clock-time without a block. Now larger, the pool will tend to hit a block in less wall-clock-time. Of course it takes just as long in share-tick-time, and gets divided over more separate contributors in the last-N window, so the acceleration is exactly offset by reduction in payout. Neither hopper nor veteran gains or loses expectation from the piling in.

But, they all gain from the lower variance, as more trials in the same wall-clock-time means better convergence to PPS-like payouts. So to the extent subscribers to the gambler's fallacy do jump in after unlucky periods, they reduce variance just at those times when it becomes embarrassing to the pool. A simple graph that obscured hashrate changes over time might make such a pool look unnaturally lucky.
Remember that Bitcoin is still beta software. Don't put all of your money into BTC!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711697688
Hero Member
*
Offline Offline

Posts: 1711697688

View Profile Personal Message (Offline)

Ignore
1711697688
Reply with quote  #2

1711697688
Report to moderator
shamathana
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 22, 2011, 11:27:22 PM
 #22

PPS is king for miners obviously, but that means I'd be left paying them out of pocket at a loss. I could only afford that at probably 15% fee, which is IMO ridiculous. MaxPPS is the only viable way to do anything even close to feeless PPS.
make ur offer :-P
bitcoins.lc sharevalue is atm @ 9,9972462987887*10^-5
ur's is atm @ 6,93413218269838*10^-5
deepbit.net with pps is @ 5,129803015564*10^-5
In human-readable decimal:
bitcoins.lc and (current) Eligius are proportional. So there is no "share value" to speak of.
Actual value of a share at the current difficulty is 0.000056996941566467068322407
deepbit.net is (in normal decimal number format) 0.00005129803015564
Eligius would be, if MaxPPS is used, about 0.000056996884569525500216354

and whats with the 15% with pps, don't "just" need a financial cussion to start with and after that just some % to keep it filled?
Yes, that % is 15.
u call it humanreadable when it starts with lots of zeros? for me 5,..*10^-5 as an average sharevalue is easierer to remember, just two fives. since nobody uses m(illi)btc (10^-3) or µ(icro)btc (10^-6), i stick to the scientific method, which the google calculator and libreofficecalc conveniently use.

anyway if i understand bc correctly the average sharevalue should be 50 / (877 226 + (2 / 3)) = 5.69978113 × 10^-5 as u said.
but why then are urs and the one from bitcoins.lc so much higher? both are overall (2weeks) values, since i began mining. so they should be quite evened out, or does that need even more time? but they are way to high and prop from deepbit is to low @ 3,8*10^-5.
however those values came to be, since one mines for profit, one should join the server with the highest sharevalue.


To the extent people believe the 'something's-due' fallacy, it could be self-limiting. Superstitious people may pile into a pool that seems to have gone a long wall-clock-time without a block. Now larger, the pool will tend to hit a block in less wall-clock-time. Of course it takes just as long in share-tick-time, and gets divided over more separate contributors in the last-N window, so the acceleration is exactly offset by reduction in payout. Neither hopper nor veteran gains or loses expectation from the piling in.

it's not about "wall-clock-time".
maybe i misused some words. to carify "long" "fast" "lucky" "unlucky" and other don't always refer to the wall-clock-time, but mostly refer to the amount of shares, which were needed to complete a block and if the sum was below oder above average(877226.66).
futhermore ur case refers to (nearly) everybody hopping, which destroys the gain in both prop and pplns.

But, they all gain from the lower variance, as more trials in the same wall-clock-time means better convergence to PPS-like payouts. So to the extent subscribers to the gambler's fallacy do jump in after unlucky periods, they reduce variance just at those times when it becomes embarrassing to the pool. A simple graph that obscured hashrate changes over time might make such a pool look unnaturally lucky.
with pplns there will be timely long rounds too, because of a lot of hoppers. the abandonment problem just shifts from the end to the beginning.
in prop every hopper leaves to the end so the speed gets slower with time.
with pplns the speed is directly slow at the beginning because everybody leaves after the round is completed. and as no shares get completed no hopper rejoins. and as the speed is crippled, normal ppl propably won't join too, because they won't get paid in a long time. crippling the pool even further.

There is no such thing as 'this pool is due'. There is no way to tell, based on history, that a pool is going to hit more than average blocks soon. So there's no way to determine now is a better or worse time than average for participation in PPLNS.

there is also no such thing as the next round WILL be a fast one in prop, that's not how it works. if it's short u made a hefty profit, if it's long u switch pools to minimize loses, or even hit a short round there. thing is on average ur on top, because short rounds make a good profit and long round aren't as bad and can trigger a good profit from the other pool evening out the loses made on the first pool. -> ur lucky = big profits, unlucky = not real loses => overall gain.

same thing with pplns. if the next round is fast: triple pay. if it's long u started quite late so it's still twice the reward, meaning nothing lost just average.  -> ur lucky = big profits, unlucky = not real loses => overall gain.

in both cases u have an overall gain, because the third case (below average) does not/much less likely exists.
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 22, 2011, 11:42:03 PM
 #23

anyway if i understand bc correctly the average sharevalue should be 50 / (877 226 + (2 / 3)) = 5.69978113 × 10^-5 as u said.
That's if each share is difficulty 1. Pool shares are actually slightly lower difficulty, so you get the number I posted.

but why then are urs and the one from bitcoins.lc so much higher? both are overall (2weeks) values, since i began mining. so they should be quite evened out, or does that need even more time? but they are way to high and prop from deepbit is to low @ 3,8*10^-5.
however those values came to be, since one mines for profit, one should join the server with the highest sharevalue.
The past 2 weeks includes different difficulties. At the last difficulty, shares were of course worth more.

futhermore ur case refers to (nearly) everybody hopping, which destroys the gain in both prop and pplns.
If there is ever a benefit to hopping, it is inevitable that everyone will do it, thus killing the pool.

shamathana
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 23, 2011, 12:19:17 AM
 #24

anyway if i understand bc correctly the average sharevalue should be 50 / (877 226 + (2 / 3)) = 5.69978113 × 10^-5 as u said.
That's if each share is difficulty 1. Pool shares are actually slightly lower difficulty, so you get the number I posted.
so how do you calculate it then?
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 23, 2011, 12:51:09 AM
 #25

anyway if i understand bc correctly the average sharevalue should be 50 / (877 226 + (2 / 3)) = 5.69978113 × 10^-5 as u said.
That's if each share is difficulty 1. Pool shares are actually slightly lower difficulty, so you get the number I posted.
so how do you calculate it then?
I do it in tonal: 0. / diff

phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1019



View Profile
June 23, 2011, 03:56:59 PM
 #26

I finally have real-world example graphs for most payout methods (warning: heavy-load webpage), based on real-world data from Eligius for a random ~800 MHz miner over a ~4.5 day period. I also simulated the graphs as if he were pool hopping by reassigning his shares beyond 43% of a block to another user. This way, you can see visually how he would have been paid under the Slush Score, Proportional, Maximum PPS, PPS, and PPLNS systems. I would have added the Geometric method too, but I couldn't figure out how to make it work.

The pool hopper spends about 2/3 of his time mining for other pools.

Please use this thread to comment on the various methods (especially as they relate to Eligius's future), nominate new methods (which I might simulate a graph for, if it seems sensible), etc...

Edit: Nominations for other methods should be made in this thread

These graphs took many hours to code and generate. If you find them useful, please donate: 12GJ27Fr9Wme2JT3ZkQMhzvHXNE8MXrAux

P.S. congrats 1AjsBb..., you're famous!

MaxPPS seems best to me.

This goes under pool maintenance. Take a 0.5% fee already.


Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 23, 2011, 04:01:03 PM
 #27

This goes under pool maintenance. Take a 0.5% fee already.
These graphs are potentially useful to other pools too, so hoping they might donate too Wink

shamathana
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 23, 2011, 05:35:45 PM
 #28

I do it in tonal: 0. / diff

what's tonal? and what are those symbols behind the "0." and before the "/ diff"?
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 23, 2011, 06:08:07 PM
 #29

I do it in tonal: 0. / diff

what's tonal? and what are those symbols behind the "0." and before the "/ diff"?
Tonal is a superior number system originally devised in 1862. The equivalent in the newer hexadecimal format is 0.ffff

HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 23, 2011, 08:05:09 PM
 #30

But, they all gain from the lower variance, as more trials in the same wall-clock-time means better convergence to PPS-like payouts. So to the extent subscribers to the gambler's fallacy do jump in after unlucky periods, they reduce variance just at those times when it becomes embarrassing to the pool. A simple graph that obscured hashrate changes over time might make such a pool look unnaturally lucky.
with pplns there will be timely long rounds too, because of a lot of hoppers. the abandonment problem just shifts from the end to the beginning.
in prop every hopper leaves to the end so the speed gets slower with time.
with pplns the speed is directly slow at the beginning because everybody leaves after the round is completed. and as no shares get completed no hopper rejoins. and as the speed is crippled, normal ppl propably won't join too, because they won't get paid in a long time. crippling the pool even further.

Your analysis seems to assume there's some benefit under PPLNS from hopping in and out, so a lot of people will do it. There's no benefit, so it will only be a small group of superstitious people.

At most, when a lot of people join, the variance goes down.  That's the same for every pool and payment scheme, more participants equals more frequent but smaller payments. It always attracts some people to the largest pools or those they expect to be largest.

If irrational superstitious hoppers make a PPLNS pool larger when there has been a long period without a generated block, that just makes the pool more attractive to rational variance-minimizers and fuss-minimizers, seeking a fair pool requiring minimum attention.

So lets say the hoppers leave after a generation in a futile search for higher returns elsewhere. Note that they are then increasing the variance of their still-alive PPLNS shares so this hop is even worse than neutral for one possible goal.

Some of the variance-minimizers and fuss-minimizers who joined during the hopper inrush are likely to stay. Each seasonal cycle of irrational hoppers should leave the pool with a larger base. And slowly train the hoppers to stop wasting their effort.
shamathana
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 23, 2011, 11:06:22 PM
 #31

Tonal is a superior number system originally devised in 1862. The equivalent in the newer hexadecimal format is 0.ffff
and why didn't it prevail?

and where do u get the 0.ffff from, which should be 65535/16^4 right? and the "diff" is the difficulty(http://blockexplorer.com/q/getdifficulty) in ton/hex?

Your analysis seems to assume there's some benefit under PPLNS from hopping in and out, so a lot of people will do it. There's no benefit, so it will only be a small group of superstitious people.
There's no benefit? what makes u believe that? just a statement, but no verification isn't enough.

lets examine a few examples.
Code:
expanation:
y-axis(up): reward paid per quarter round in halfs each digit
x-axis(right): relative time(not time! that depends on the pools h/s) in average quarter round shares(877226/4) each digit
after a block is solved the numbers start counting up again: 23Solved123456Solved1234Solved1....

average round lenght: 1234
fast round: 12 (half the shares needed)
long round: 123456 (1,5 times the shares needed)
even longer: 12345678 (double the shares needed)

normal miner/hopper getting paid a half: #
hopper getting paid a half, but not normal miner: W
the hopper hops from the end of the pplns round to a normal pps-server, and when the round is on average halfway through the hopper joins the pplns again:
12hopper joins34hopper leaves12hopperjoins34hopper leaves12hopperjoins34...

#
#
2 for this segment(~220k submited shares) the miner/hopper got paid two halfs(average) normal pps payout


#
3 for this segment(~220k submited shares) the miner/hopper got paid 1 half(50% of average)

#
#
#
4 for this segment the miner/hopper got paid 3 halfs(150% of average)

W
#
1  for this segment the miner got paid 1 half(#) and the hopper got paid 2 halfs(#+W)
i hope u get what i mean, lets look at the corresponding graphs:

just average rounds: normals and hoppers get paid the same, except the miner gets all his money from the pplns-server, where as the hopper gets 50% from the pplns (34), and the other(12) paid from the pps-server. hopping gives neither an advantage nor a disadvantage:
Code:
            ########           
        ########
    ########   
########                 
12341234123412341234


now a longer round appears(123456), and the hopper gets more(all W's) than the normals. so it averages out for the hopper, but the normals have a net loss:
Code:
              ########           
        WW########                                       
    WW########                   
########                         
####                         
1234123412345612341234


now an even longer round occurs(12345678). the normals get two average rounds(12341234) just halfs, where as the hopper just gets 1 normal round of halfs(3434), so he gets less of the deficit from hopping:
Code:
                         
                ########       
        WW  ########             
    WW  ########         
########                   
####
123412341234567812341234


now an even longer round occurs(123456789abc, triple size of average). even the hopper gets hit by lots of "just halfs" and even a part nothing, which can be minimized by joining even later. but despite that, his balance is again better than of the normals:
Code:
                ########         
            ########         
    WW #########       
####WW
1234123456789abc12341234

a shorter than average round(12).hopper gets paid the averages on 12 from the pps, and is there to gain the triplepay from the (34) parts from the pplns. hopping gives again neither an advantes nor a disadvantage:
Code:
          ########     
      ########         
  ########       
########             
####               
123412341212341234

as u can see hopping on prop as on pplns has some advantages and not as much disadvantages of joining said pool.

If irrational superstitious hoppers make a PPLNS pool larger when there has been a long period without a generated block, that just makes the pool more attractive to rational variance-minimizers and fuss-minimizers, seeking a fair pool requiring minimum attention.
the pool gets more attractive? again just a statement, proof is needed too! can only be, because of the faster but smaller payouts(increased h/s).
but with lots of hoppers there also much risk for the normal miners mining very long for nearly nothing(relative time as pointed out above). the 12 parts take more time because only the normals mine and the hoppers are gone, additionally those parts have a good chance of being paid just once or even nothing at all(wich should be clear looking at the graphs above). it's the oppotise from prop! on prop u dont want to mine the last shares of a block and on pplns u dont want to mine the first shares.

So lets say the hoppers leave after a generation in a futile search for higher returns elsewhere. Note that they are then increasing the variance of their still-alive PPLNS shares so this hop is even worse than neutral for one possible goal.

Some of the variance-minimizers and fuss-minimizers who joined during the hopper inrush are likely to stay. Each seasonal cycle of irrational hoppers should leave the pool with a larger base. And slowly train the hoppers to stop wasting their effort.
variance? i'm not quite sure what u want to point out. but i guess: the worth of their already mined shares is not affected if the keep mining or not.
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 23, 2011, 11:12:24 PM
 #32

Tonal is a superior number system originally devised in 1862. The equivalent in the newer hexadecimal format is 0.ffff
and why didn't it prevail?
Globally, SI/metric prevailed, mainly because it was illegal to use anything but SI/metric.

Any other suggestions for payout methods to consider? We're running out of time fast, so I need to get the poll options finished soon...

shamathana
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 23, 2011, 11:31:53 PM
 #33

Globally, SI/metric prevailed, mainly because it was illegal to use anything but SI/metric.

perhaps he should have done that *G
still remains:
and where do u get the 0.ffff from, which should be 65535/16^4 right? and the "diff" is the difficulty(http://blockexplorer.com/q/getdifficulty) in ton/hex?
and the difficulty is the average number of shares needed to solve a block?

Any other suggestions for payout methods to consider? We're running out of time fast, so I need to get the poll options finished soon...

don't look at me i'm fairly new, but u need time to vote too, or just 3 people will vote ;-P  should be about 40h before the next change?!
HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 24, 2011, 04:48:02 AM
 #34

@shamathana

Of course you can contrive scenarios where certain entry/exit-patterns get more; payments do have a random component and so some patterns will result in more or less in the short run. (Sometimes betting on red at the roulette wheel results in gains over the next few spins.)

But there are an equal prevalence of scenarios where those same entry/exit-patterns, using information available at the moment of participate/don't-participate decisionmaking, get less.

The 'proof' you request is trivial: PPLNS payments are completely determined by a formula whose only inputs are future unknowable events uncorrelated with the recent past. There is thus no way to look at the history of a pool and decide, 'now if I enter(leave) I will get more(less)'. At every moment, the prospective value of participating is equal. Hence, no hopping by any rational miner.

Even a miner who is able to predict with certainty an upcoming inrush of new participants, or outrush, doesn't gain any net gain in expected-return. More co-miners mean a block will be hit quicker (by wall-clock time), but also old shares will expire quicker (by wall-clock time). Knowing an influx or outflux is imminent just means variance over time will fall or rise respectively, as is the case with any pool expanding or contracting. Not that expected return will rise or fall.



SoreGums
Full Member
***
Offline Offline

Activity: 129
Merit: 100



View Profile
June 24, 2011, 10:18:02 AM
 #35

maximumpps stands against the no registration needed, because every time u change, u have to get ur maximum up again.
You still don't need to register. I agree, the lack of being able to change addresses on a whim is a concern. Any suggestions to deal with it?
what if the password is used to keep track of the user?

then its upto us to figure a unique password and use it?
then we could use different address per gpu as well...

maybe have some sort of minimum requirement, like must be minimum 32char hex to qualify as a password that links things together.
if i'm able to pick the same 32char hex string as you that would be pretty amazing...

ok so now a miner has 3 gpu's and uses 3 addresses which one gets the reward?
well they just get the reward as if they weren't linked...
then the user can just keep changing the address and after 7 days of an address being inactive distribute, the reward among the active addresses?

this obviously introduces some complexity to the code...
shamathana
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 24, 2011, 11:54:46 AM
 #36

@shamathana

Of course you can contrive scenarios where certain entry/exit-patterns get more; payments do have a random component and so some patterns will result in more or less in the short run. (Sometimes betting on red at the roulette wheel results in gains over the next few spins.)

But there are an equal prevalence of scenarios where those same entry/exit-patterns, using information available at the moment of participate/don't-participate decisionmaking, get less.
really? please show me i do not see that! i should have processed all cases: shorter, average and longer rounds. and they look like hopping prop too me. shorter rounds: u get all of the extra rewards, average rounds: you even out with the normals, longer rounds u get less from the deficit(which is not the excatly right word since u still get paid, but not so much as u should have on average. yes i speak english as a foreign laguange :-P).

The 'proof' you request is trivial: PPLNS payments are completely determined by a formula whose only inputs are future unknowable events uncorrelated with the recent past. There is thus no way to look at the history of a pool and decide, 'now if I enter(leave) I will get more(less)'. At every moment, the prospective value of participating is equal. Hence, no hopping by any rational miner.
@ future unknowable events uncorrelated with the recent past
yes, and true for prop too. the deciding factor is in hopping prop/pplns, that if the round is better than average u get the reward, but if it's below average u still make more than the normalo. i can go into more details if u wish, but first i will eat.

@At every moment, the prospective value of participating is equal
equally random, because it is infuenced by the N = difficulty * 2 shares still wanting to be generated after urs.

Even a miner who is able to predict with certainty an upcoming inrush of new participants, or outrush, doesn't gain any net gain in expected-return. More co-miners mean a block will be hit quicker (by wall-clock time), but also old shares will expire quicker (by wall-clock time). Knowing an influx or outflux is imminent just means variance over time will fall or rise respectively, as is the case with any pool expanding or contracting. Not that expected return will rise or fall.
yes true, but still not the point. nobody knows the future and hoppers don't know it either. they KNOW if they hop they get most of the sharevalue increases(shorter rounds) and less of the shavevalue decreases(longer rounds) from the pool.
HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 24, 2011, 03:41:28 PM
 #37

The 'proof' you request is trivial: PPLNS payments are completely determined by a formula whose only inputs are future unknowable events uncorrelated with the recent past. There is thus no way to look at the history of a pool and decide, 'now if I enter(leave) I will get more(less)'. At every moment, the prospective value of participating is equal. Hence, no hopping by any rational miner.
@ future unknowable events uncorrelated with the recent past
yes, and true for prop too. the deciding factor is in hopping prop/pplns, that if the round is better than average u get the reward, but if it's below average u still make more than the normalo. i can go into more details if u wish, but first i will eat.

No, pure proportional payments are not strictly a function of future unknowable events. In pure proportional there is also one important factor which affects payouts and is already known: how long ago the last block was found. Nothing before that block is paid. Thus a hopper knows when an extra-valuable participation period is happening (early), or when an less-valuable participation period is happening (late).

This is very different from PPLNS. There is no 'round' that resets when random generations happen, affecting how future shares will be paid. Every single share is in its own 'round' that last lasts exactly N shares into the future. There are some periods that in retrospect turn out to be better, but it is impossible to predict those periods in advance.

The next N shares to be submitted from all miners will completely determine what a share will be paid. Those next N shares are all of unknowable (but equal on average) value. Their value has no relation to the timing of past generation fees. Hence, there is a consistent equal average return to participating.


Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 24, 2011, 04:45:59 PM
 #38

Poll: https://forum.bitcoin.org/index.php?topic=21999.0

Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 19, 2011, 03:49:53 PM
 #39

New version now available

Changes:
  • New real-world data from Eligius-Su over the course of a week (based on 1BZSTyy...)
  • Support for SMPPS variants:
    • Equalized Shared Maximum Pay Per Share (ESMPPS, aka "SMPPS7")
    • Proportional / Pay Per Share (PPPS, aka "xPPS")
    • Capped Pay Per Share with Backpay

Note that Geometric and RSMPPS are listed for completeness, but are 404.

twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
July 19, 2011, 06:36:59 PM
 #40

New real-world data from Eligius-Su over the course of a week (based on 1BZSTyy...)

I am only seeing data for a 2.5 day time window.  Is it supposed to be a week's worth of data or did I misunderstand?

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
Pages: « 1 [2] 3 »  All
  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!