Bitcoin Forum
December 10, 2016, 07:01:06 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
Author Topic: bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)  (Read 76295 times)
lebuen
Member
**
Offline Offline

Activity: 106


View Profile
July 14, 2011, 11:19:20 AM
 #381

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".
1481396466
Hero Member
*
Offline Offline

Posts: 1481396466

View Profile Personal Message (Offline)

Ignore
1481396466
Reply with quote  #2

1481396466
Report to moderator
1481396466
Hero Member
*
Offline Offline

Posts: 1481396466

View Profile Personal Message (Offline)

Ignore
1481396466
Reply with quote  #2

1481396466
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481396466
Hero Member
*
Offline Offline

Posts: 1481396466

View Profile Personal Message (Offline)

Ignore
1481396466
Reply with quote  #2

1481396466
Report to moderator
1481396466
Hero Member
*
Offline Offline

Posts: 1481396466

View Profile Personal Message (Offline)

Ignore
1481396466
Reply with quote  #2

1481396466
Report to moderator
1481396466
Hero Member
*
Offline Offline

Posts: 1481396466

View Profile Personal Message (Offline)

Ignore
1481396466
Reply with quote  #2

1481396466
Report to moderator
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 14, 2011, 01:26:54 PM
 #382

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 14, 2011, 04:59:52 PM
 #383

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

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
lowentropy
Member
**
Offline Offline

Activity: 84


View Profile WWW
July 14, 2011, 06:30:30 PM
 #384

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.

Mine @  <http://pool.bitp.it>
Chat with us @ irc://irc.freenode.net/#bitp.it
Learn more about our pool @ <http://forum.bitcoin.org/index.php?topic=12181.0>
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 08:07:26 PM
 #385

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
Hero Member
*****
Offline Offline

Activity: 868


luck is just a share away


View Profile
July 14, 2011, 08:09:50 PM
 #386

i prefer user transparency over stats delay:

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

(just join us Smiley
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 14, 2011, 09:05:45 PM
 #387

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.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
lowentropy
Member
**
Offline Offline

Activity: 84


View Profile WWW
July 14, 2011, 09:09:57 PM
 #388

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?

Mine @  <http://pool.bitp.it>
Chat with us @ irc://irc.freenode.net/#bitp.it
Learn more about our pool @ <http://forum.bitcoin.org/index.php?topic=12181.0>
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 14, 2011, 11:00:31 PM
 #389

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.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 01:12:35 AM
 #390

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 01:25:46 AM
 #391

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?

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
owowo
Jr. Member
*
Offline Offline

Activity: 43


View Profile
July 15, 2011, 01:51:30 AM
 #392

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
Jr. Member
*
Offline Offline

Activity: 30


View Profile
July 15, 2011, 01:53:59 AM
 #393

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
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 15, 2011, 07:13:23 AM
 #394

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

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
luffy
Hero Member
*****
Offline Offline

Activity: 606



View Profile
July 15, 2011, 07:17:48 AM
 #395

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

Activity: 504


FPGA Mining LLC


View Profile WWW
July 15, 2011, 09:00:25 AM
 #396

you should set a poll in order to vote what system we want Wink
now i see that this ~0% stale pool would be ideal for SMPPS Wink
it has the potencial to be the best pool ever Cheesy
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.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 15, 2011, 09:13:45 AM
 #397

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

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
luffy
Hero Member
*****
Offline Offline

Activity: 606



View Profile
July 15, 2011, 09:58:45 AM
 #398

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

Activity: 1848


View Profile
July 15, 2011, 09:59:26 AM
 #399

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.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 15, 2011, 10:04:36 AM
 #400

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!