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.

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

so how do you calculate it then?

That's if each share is difficulty 1. Pool shares are actually slightly lower difficulty, so you get the number I posted.

The past 2 weeks includes different difficulties. At the last difficulty, shares were of course worth more.

If there is ever a benefit to hopping, it is inevitable that everyone will do it, thus killing the pool.

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.



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.

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

Regarding PPLNS:


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.

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

Yes, that % is 15.

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



and whats with the 15% with pps, don't u "just" need a financial cussion to start with and after that just some % to keep it filled?

Whether it's happening or not, it's basically stupid to not hop a prop. pool. And doing so will kill them.

MaxPPS isn't PPS. PPS carries an infinite risk for the pool operator. MaxPPS is PPS without that risk. ie, you get as much as PPS would pay, so long as it doesn't kill the pool.
No matter which system is used, including MaxPPS, everything you earn will still be paid out after a week.

Every system proposed averages out for ordinary miners.

Maybe, but this might be flawed with the gambler's fallacy: there's no reason to expect a short round after a long one. And really, there are no rounds with PPLNS at all.

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.

if thats true, then why did u implement it in the first place?! why don't u know if they r hopping, aren't u the admin with access to lots of stats?! because if they r not, we could cut the whole thread quite short! and ur pools hashpower rises and rises.

not with keeping maxpps. but it's sounds shitty anyway maxpps = pps or less. shouldnt pps stand for a guaranteed value, which maxpps does not? also i chose eligius, because in the end everything gets paid out after a week, but with maxpps that would not be the case. so i would change the server, because it looks like the worst system to me.

ahh u should stress the retroactively part, where u get paid on average just half but it dates back twice as much, so it should average out(except really long round which own miners). now it makes sense.

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.

all those systems have their ups and downs. but if u wanna combat hopping, pplns doesn't look to good. pps should be king, or if u wanna burden the miners with the risk it's maxpps.

Then it can pay from future generation, at the expense of the excess getting into the pool wallet. It all evens out, that's why it's even workable.

Since it isn't theirs, it isn't necessarily in reserve. Of course, not keeping it as a reserve would create a liability to the pool operator should they come back later. Since pool hopping will be pointless and PPS generally a losing proposition, I expect there won't be all that much size to these abandoned NRC (non-reward credits). Specifying an expiration for such credits might be a good idea just in case-- perhaps it could help defer/reduce fees.

You are right. Yet, maxPPS never pays more than proportional, and, you said it yourself, PPLNS payouts are very close to the proportional payouts. I'd rather have my payouts depend on the pool's luck rather (and get them immediately) than having constantly an (even tiny) amount of my reward "withhold" by the pool in case of "unlucky" rounds.

I understand that's the logic of MaxPPS. But, they are real BTC funds delivered from the blockchain. They are under the control of the pool operator. And, if someone who has already built up a pending 'earnings' amount later becomes due that BTC by having their 'value' catch up, they need those funds to be safe in order to get paid.

What if in the meantime, you had a security break-in and those BTC were stolen? Or a catastrophic data-loss situation where you lost the keys to pay that out?

Yes, this is also a risk with minimum payouts but it's larger with MaxPPS. And given inactivity-payouts, it's a capped risk. Amounts due tend toward zero very quickly. With MaxPPS, credits-available-if-you-mine, which are matched by real pool-operator BTC held balances, can grow indefinitely.. especially if many miners wander away.

And, since those funds won't be used to pay anyone else, for example someone new who generates extra 'value' but not yet matching earnings, it's not the full story to say those funds aren't "due to anyone yet". They seem to be in an account-specific reserve. That makes them very susceptible to indefinite abandonment.

If that account never shows up with more mining, to get their 'earnings' and 'value' caught up, is that amount held in reserve in case they again show up forever? Or is it eventually redeployed to pool costs or other recently-active miners?

Practically, you might want to declare an expiration time for these unvested earnings, before it becomes an issue.

This is not relevant, as it isn't funds due to anyone yet.

They get paid for the work they did. The remainder is not owed to them, and won't be until they do the work to earn it.

It's not a reserve. They have non-reward credit noted on their account, in case they decide to mine again, and at that time the pool might owe them more than it makes at that point in time.

Basically, MaxPPS is nothing more or less than PPS with safeguards for the pool operator, which allows him to charge a lower fee, or even no fee at all.

Even though it is more complicated to wrap your head around, I prefer MaxPPS.  It is a smoother payout than proportional, doesn't reward pool hopper if they bail on long blocks, and doesn't risk the pool being shut down from losing BTC like PPS does.

PPLNS has simpler math, but that doesn't mean the logic of it is easy to grasp. I guess the concept is that each time a block is found, we'll pay you for your relative contribution to the pool's total hashrate over the recent past (not specific to the block that was just found).  Once you get past the start, the payout pattern seems identical to proportional for ordinary miners, so it isn't any smoother of a curve.  You lose out right at the start because for the first couple blocks you are not getting credited for shares from previous blocks.  You recoup that initial deficit eventually when you stop mining and keep getting paid even after you quit (for the last few shares you submitted).

I prefer MaxPPS simply because it has more consistent payouts than PPLNS (which has payouts that vary just as much as proportional).  With MaxPPS, on any given 24 hour period, I will get paid closer to what I would have been paid with PPS.

That said, I could live with either.

Yes, all systems require balances to meet some minimum threshold (or age).

MaxPPS also holds at the pool amounts generated that aren't yet matched by 'value'. These could be larger than the minimum payout.

To illustrate with an extreme example, assume a MaxPPS system with 50 miners. each submits 1 share, the 50th makes a full block. They each get 1BTC in 'earnings' but only an infinitesimal amount in 'value'. So they are credited tiny amounts, but (50-epsilon) is held indefinitely by the pool operator, until some overlong-round arrives.

If the next 10 rounds all take exactly the expected amount of shares, then for those, they each get 1BTC value/earnings/payout. But until an overlong round arrives, that first-round surplus is still held at the pool.

If some miners dabble and then leave, and thus never catch up on 'value', that reserve is held.. forever? (Or does it eventually revert to the operator or other miners?)

I'm not sure this is a real benefit for practical reasons:

• Full record-keeping is still needed for auditing
• Reserve-holding is needed only until the minimum payout is met (and there is enough generation to make the payouts) under all systems

It does remove the requirement for maintaining non-reward credit, but that is strictly a negative of the MaxPPS system, not so much a benefit of this one IMO.

---

Very nice charts!

Regarding how they show PPLNS (http://eligius.st/wiki/index.php/Pay-Per-Last-N-Shares):

If people care a lot about some shares earning zero after unlucky periods, then N could be much larger: say difficulty * 10. This means it takes longer before a contributed share is sure it's collected all its payments, maybe days, but also that hardly any shares get a total goose-egg. In contrast to MaxPPS, it is not required that a miner continue contributing in hopes things eventually 'even out' on their account. They eventually get credited their earnings-by-rule (or the shares expire by moving out of the last-N-window) as long as the pool continues operating.

In my mind one of the largest benefits, worthy of highlighting via a bottom-bullet, is that PPLNS minimizes the record-keeping and reserve-holding of the pool operator. Even with 100% trust in the operator, holding a reserve balance at the pool involves risks: real-life crises, security-break-ins, bitcoin economy crashes, etc. A system which allows most accounts to be 'zeroed' asap after generation fees earned means less risk.

(A way to indicate this graphically could be to show the actual surplus of generation fees over payouts as another data series, or in the case of pure PPS, the required deficit the operator sometimes has to cover. The determinism of PPLNS means neither surplus nor deficit need be carried at any point.)

Whether people are actually doing it or  not, I don't know. I don't think the hashrate graph gives enough info to tell. With proportional, pool hopping is a good idea and a miner's right. The problem is that it will kill the pools involved eventually.

Slush and PPS are only on there for comparison/reference. I'm not considering either as viable options.

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?

Except that the last N shares are always paid. So except for blocks at least 2*diff shares long, your shares on the previous block(s) would get paid more than once.

The proportional system is self-defeating due to pool hopping. As far as actual earnings, the graphs clearly show that for the ordinary miner, all the systems pay more or less the same.

is poolhopping still an issue? the graphs i saw on eligius, are quite constant 24/7.

if i wanted slush, i'd go to slushs server.

if i wanted pps, i'd go to one of the many pps-servers.

maximumpps stands against the no registration needed, because every time u change, u have to get ur maximum up again.

pplns looks like the über ripoff:#
Variables: N = difficulty * 2
# Easy math: (your shares / N shares) * reward
basically it's like prop but the size is always two times time the average ( N = difficulty * 2). meaning it's averaged out prop/2.
on averge u would be ripped off 50%, on faster rounds even more, on doulbe than average rounds it would be like prop, and on longer than 2*average round u would decrease the 50%profit of the 50btc + fees margain of the operator.

eligius is the best(2nd best when it comes to payouts only) of 5 servers i have tested. never change a running system, just fix the us-server.

It's a pretty interesting chart. Thanks for your work on it. I will send the results of a few hours of my mining work to you. Which is not that much, but still.


A fair reward for the pool hopper is probably about 4.2/3 = 1.4BTC. With prop, he gets 2.7BTC. That's pretty.. unfair.

(Now I notice I could have figured out the pool hopper's away-from-poolness ratio by looking at PPS..)

About 2/3 of the pool hopper's shares were spent mining for other pools.

I'd like to know how long the pool hopper is not actively mining because the pool is above 43% of the difficulty (that is, how much time can the hopper spend on a different pool?). In percent.

It helps to figure out by how much the pool hopper gets overpaid for each payout method.

That's very nice. PPLNS is my favorite by the way ! 

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!

Click here for latest version