Topic: bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!) - page 13. (Read 80568 times)

I think SMPPS or PPLNS would discourage the hoppers, especially pplns.. since the block right now takes longer ppl are leaving and we dropped down 50% hashrate... I personally am more fascinated with prop, as it has more like a goldwashing experience ;o) ,... but for the pool to grow SMPPS or PPLNS would be better.

Agreed,

Real time stats are just too much fun. I'd hate to have to give those away.

I think TheSeven worded it best. SMPPS isn't all about preventing pool hopping, that is just a convient side effect. SMPPS reduces variance, and (in a small pool) reducing variance is a big plus. Other than pure PPS (which could bankrupt a pool), there isn't anything that I know of that will lower variance nearly as much as SMPPS.

I am hearing a lot of people in favor of SMPPS, and I've also heard a few requests for clarification on the payout scheme. But, what I haven't heard is any people saying that they're against such a system. Surely somebody has a disagreement or concern of SMPPS?

Hey,

I just left a comment on that issue. I hope that helps explain the issue.

I am going to try and find cdhowie and perahps between the two of us we can find something. Also, though I don't think I mentioned it at github, we're also working with the nginx team to see if perhaps they know of a way to remove the erroneous trailing CRLF before it even enters Node.

It's very simple: You log how much each share is worth in theory (50BTC/difficulty), and how much was actually paid for it. You can forget about fully paid shares.
If funds arrive, you pick the share with the lowest payout ratio, and pay some more for it, until another share was paid less. Then that share receives some funds, and so on. This can of course be optimized algorithmically, I'm just explaining the objective.

The least-paid shares are of course the shares of the current round. So those get paid first, until they reach the payout level of the other shares. Then, shares of older non-fully-paid rounds are considered as well, until either all shares are fully paid or there are no funds left.

As long as the pool is lucky, everything will be paid out 100%. If it is unlucky, shares will be paid by excess income from older rounds. If there are no more funds, the pool will pay that round proportionally at first. However, when it becomes lucky again, it will pay for the difference, and only start to accumulate funds again once all shares are paid their PPS value.

Assuming there are 10% withholders, this would mean that in the long term all blocks will be paid about 90% of their PPS value. That way it will hurt withholders by basically introducing a dynamically adjusting fee.

If the pool first has a lucky streak, and then an unlucky streak, and never recovers above average, the older shares will of course have been fully paid, and newer shares won't be, which one could consider unfair. Doing these calculations not on a per-share but instead on a per-user basis would not only fix that, but probably also reduce calculation effort a great deal. It will however provide some incentive to do "account hopping" after a lucky streak, as especially old accounts would be paid almost nothing while the pool's luck drops.

I agree, SMPPS is mostly tempting for me because it does a very good job of reducing variance. I can't help but think that two week round could have been made less painful, due to the three lucky rounds that came before it.

I didn't fully understand your concept of achieving even payment ratios per share, but I'm very interested; can you describe the idea more?

Actually, I don't think this is really about preventing pool hopping. If you want to prevent that, go solo or score, but beware that variance will hit you even harder.

The point of a pool is to reduce variance, so the main aim is to reduce variance as much as possible while preventing scam as much as possible. This is a tradeoff.

The point of SMPPS is that it doesn't only stop pool hopping, it also reduces variance to even lower levels than proportional. So it should be seen as a way of variance reduction, not just an anti-hopping strategy. Not needing to sacrifice stats transparency makes it even better.

My personal favorite is SMPPS in "try to achieve equal payment ratio per share" mode, as described above.

i prefer user transparency over stats delay:

http://forum.bitcoin.org/index.php?topic=7760.msg363810#msg363810

(just join us

We have been discusing about Pool Hooping in the BTCGuild thread and the conclussion has been that delaying the information stops pool hoopers. The idea is that pool hooping is only profitable if you join when a new round starts. But if you dont know when a new round starts then you can not do pool hooping. So there is no need for complicated system. Just delay the information some hours and pool hooping is not posible. In BTCGuild they can probably get away with delaying the information 1 hour, but in smaller pools like this one maybe you need to delay it like 6 hours or something like that?

I think the way http://eligius.st/wiki/index.php/Shared_Maximum_PPS phrases it is confusing, but the line "If not, the miners are paid proportional to available funds.", in addition to this equation in the pseudocode: Pay each miner PPSamount / idealPayTotal * availableFunds, tells us what happens on long rounds. There is no mention of a payout queue; but it doesn't simply revert to proportional payment of 50 BTC. Instead, if switches to proportional payment of the 50 BTC plus the entire "buffer" from short rounds, instantly depleting the buffer.

As those streaks aren't predictable there should be no incentive because of them.

I interpret this differently:


So I can think of at least seven possible SMPPS variants:

• Pay regular PPS as long as possible, switch to Prop when impossible (see post above).
• Pay PPS if possible, pay Prop if impossible. Increase payout of old prop shares only if there are leftover funds in a PPS round. (Possibly with some weighing based on share age.)
• Enqueue shares for payment. They will get fully paid once enough funds are available, FIFO order. (Turns in a ponzi scheme if there are withholders? Might on the other hand discourage withholding.)
• Enqueue shares for payment, but in LIFO order. (IIUC this has a similar effect like score-based accounting.)
• Try to achieve equal payment ratio per share (see my last post), behaves like a dynamically controlled (luck and withholding dependent) averagin fee, that distributes PPS risk amongst members.
• Try to achieve a certain payout curve, like the idea above, but weighing old shares more than new ones. (Does this make sense at all?)
• Try to achieve equal payment ratio per user (see my last post, allows to kind of increase the dynamic fee retroactively, might cause "account hopping").

This was my understanding as well. I thought if reserve funds weren't enough to cover the shares from the current round it simply switch to proportional over the 50 BTC + all available reserve. No queue, everyone gets paid after every round.

At least, that was my understanding from reading luke-jr's pseudo code. Someone please correct me if I'm wrong.

http://eligius.st/~artefact2/blocks/
This should make it clear. Works good and is absolutely fair. Plus it's quite easy to understand actually, compared to your suggestions, TheSeven.

No - in case of unsufficient funds on the server, payouts are adjusted, not "left out" entirely. So the effect is not that "hard".

Yeah, this sounds like a good idea. But if the pool goes into a strike of bad luck, new users still know that they might be payed less, unless the pool goes into a strike of good luck, so its not as big but there is still a disincentive. Also, its complicated, people like simple things.

all systems have their "plus" and "minus" considering their fairness
what to choose?

So does this mean that the pool will delay new share payout until all old shares are fully paid?
If there are withholders, this would mean that they will get full payouts one day, but payouts get delayed by possibly weeks, which is very unattractive to new users.

I can thing of two alternatives which might be better (I'm not sure yet):

• Keep track of the total number of bitcoins that a share should have been paid, and try to reach the same payout level for all shares. E.g. if all old shares have been paid 70% or something, the block's reward will first be used to bring the new shares to the same level, and if there are funds left, raise the payout level of all shares. (Of course if the block before had a lower payout level than average, these shares will be brought "up to speed" first.) This ultimately tries to achieve the same payout level for all shares.
• Do the same on a per-user basis. I.e. take into account that some users might have got 100% reward from some older blocks which by now are fully paid, and others only took part in "unlucky" (or just newer) rounds which aren't fully paid yet, and try to achieve the same average payout percentage for everyone. This sounds most fair to me in the long term, but may encourage users to register a new account after a couple of lucky rounds to escape redistribution. I'm not sure if that would be worth the effort though.

Any thoughts on these models?
Oh, and +1 for SMPPS in general

Unpaid shares remain as a credit and will be paid out before "new" shares are paid out. It's like a queue, no credit gets lost.

So lets say the system gets implemented and the pool has horrible luck for two weeks. The miner will have some shares that are not payed since the reserve funds are 0. Now Bitp.it has two weeks of very good luck and creates some reserve funds. At this point some new mienrs come in. Now other two weeks of horrible luck, but this new miners get payed because the pool has available funds they did not contributed to obtain. Am I missing something?

That's not true - it's still PPS, which means it eliminates "luck" entirely for the miners. You always get paid what you'd expect in the given time from your hashing rate and current difficulty.
So the only variable for you as a miner is time and hashrate. "Long rounds" don't change your rewards, an neither are "new miners" rewarded more at any time. It's always fair.

That is awfully coincidental that you have your computers are split up two and two, and I'm only seeing two with an LP connection.

Right now, the way the logs are written out, all I see is how many LP connections per user, not per miner. I will need to jump into things to get that on a per miner basis, give me a little bit to get that info for you.