bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)

[lebuen]

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.

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.

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

[1713301055]

1713301055

[1713301055]

1713301055

[1713301055]

1713301055

[1713301055]

1713301055

[1bitc0inplz]

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.

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

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.

[TheSeven]

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.

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

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.

I interpret this differently:

The difference between a miner's actual (SMaxPPS) earnings and PPS earnings is retained as credit, and considered in future blocks.

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

[lowentropy]

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.

[hugolp]

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?

[flower1024]

i prefer user transparency over stats delay:

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

(just join us

[TheSeven]

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.

[lowentropy]

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

[TheSeven]

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?

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.

[1bitc0inplz]

Would love to use you guys as a backup, but I ran into issues with your server sending 502 Bad Gateway errors when the proxy requests work.

https://github.com/cdhowie/Bitcoin-mining-proxy/issues/38

The other pools I've tried have worked.

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.

[1bitc0inplz]

i prefer user transparency over stats delay:

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?

[owowo]

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.

[Obsi]

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.

Excellent, thanks!

[TheSeven]

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.

See http://forum.bitcoin.org/index.php?topic=12181.msg253239#msg253239 for an explanation why Score/PPLNS isn't good for a growing pool. (PPLNS will behave very similarly to Score, and actually I simplified Score to the PPLNS case in that post, so it should be applicable for both.)

[luffy]

you should set a poll in order to vote what system we want
now i see that this ~0% stale pool would be ideal for SMPPS
it has the potencial to be the best pool ever

[TheSeven]

you should set a poll in order to vote what system we want
now i see that this ~0% stale pool would be ideal for SMPPS
it has the potencial to be the best pool ever

The problem with that kind of democracy is that people often don't fully understand the implications of what they're voting for.
Ideally we should just reach a consensus within a discussion here. It seems like SMPPS is being favored, so now the question would be which of the variants that I outlined above.

[TheSeven]

Sad news... Apparently ~60% of our hashrate are pool hoppers. Time for SMPPS, me thinks.

[luffy]

i like how the SMPPS pool arsbitcoin.com is working. it has ~0.5% stales though.
this pool will be better

[Sukrim]

SMPPS has the disadvantage that the pool can be over time arbitrarily high in dept towards it's miners. If you had a maximum of hashrate during a bad luck streak, these miners will never get paid at all.

[hugolp]

SMPPS has the disadvantage that the pool can be over time arbitrarily high in dept towards it's miners. If you had a maximum of hashrate during a bad luck streak, these miners will never get paid at all.

Yes, but they would not be payed in proportional either. So its not like you are loosing anything.