Topic: Visual comparison of pool payout methods based on real-world data (Read 9143 times)

You do realize that luck has little to do with the process of "winnings", as we are all essentially rolling 20-sided dice, thousands of times...

The "illusion" of luck comes from the fact that all encryption uses at-least ONE long-ass prime-number... That number, with consideration for your "wallet-key/ID", of the pool operators... determines how "easy" it is to hit your target of x-zeros.

EG, crypt any number by 3, and you will never have a zero. crypt any number by 13, and you will have a few zeros. crypt any number by 101, and you get a lot of zeros easily... The "number" is the result of the block-data. The crypt, is essentially the pool operators "wallet-key/ID" we are all using as the base-line to find the "solution" to the block. (The leading 00000's for the win.)

If you look at any pools results, it is exactly the same results of prime-number intersections, as seen in perlin-noise-waves. Highly predictable by the way. I can almost guess with about a 80% accuracy, when our next block will be, and how long our next hot-run will be, and how long it will take us to find that next slow-block. (The luck part, which is little to do with it, has to do with someone-else's "noise" taking our win, at that intersection of our divisor-prime, versus their divisor prime.)

EG... If you are a pool operator, you should be trying a new wallet every day. If the wallet has poorer results than your best wallet, scrap it. (Easy test is to see how fast and how close to a difficulty of 32 the shares come. If most are 32/32 that is a hot wallet. If they bounce all around like 487/32, 32/32, 14k/32, 87/32, 99/32... then it is a messy wallet with little chance of "good luck"... that wallet-key/ID is a "3" or a "7", with few results leading to a trailing zero result.)

Do your pool-joiners a favor, and give them a fighting chance... use a wallet that has the actual ability to create a difficulty 18,000,000 block. Or you will see most of your times lengthen to hours and hours, and others will quickly find blocks that could have been yours, because you were crunching away with a dirty key.

Plot your pool-wallet-key/ID results... you can visually see the better ones that way. (You need more than one users results to see what needs to be seen.)

I love this graph. However, it doesn't work right in Chrome btw, MSIE is needed. Also, if you added CGM and CPPSRB one day that'd be epic.

Looks great.  Are there definitions of the SMPPS variations somewhere?  I am unfamiliar with several of them (equalized pps, prop/pps, capped pps).

Ok, got the issues worked out and regenerated everything based on July 8 to 20 (12 days). Since Eligius-Su has had absurdly good luck on average, I decided to artificially drop 1/3 of the blocks to make it have somewhat bad luck. Since most of the PPS systems pay exactly PPS during good luck, I consider the bad luck scenario to be of more importance to "get right". In addition, I am now simulating 3 miners: the default constant 800 MH/s, the hopper 800 MH/s who only mines for the first 43% of difficulty shares, and the "newbie" 800 MH/s who mines constantly starting 2/3 into the graph.

http://eligius.st/~luke-jr/samples/800MH-3/

Hrm, you're right. That's odd. It's supposed to be Jul 16 - 25 :/

OH WAIT >_<

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?

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.

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

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.

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

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

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.

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

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.

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?


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

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

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?

There's no benefit? what makes u believe that? just a statement, but no verification isn't enough.

lets examine a few examples.
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:


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:


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:


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:

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:

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

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.

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.

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.

Tonal is a superior number system originally devised in 1862. The equivalent in the newer hexadecimal format is 0.ffff

what's tonal? and what are those symbols behind the "0." and before the "/ diff"?

These graphs are potentially useful to other pools too, so hoping they might donate too

MaxPPS seems best to me.

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