Bitcoin Forum
April 17, 2014, 04:19:09 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   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 48637 times)
Sukrim
Hero Member
*****
Offline Offline

Activity: 994


View Profile

Ignore
July 15, 2011, 10:11:38 AM
 #401

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.
In proportional they would get paid as soon as the next block is found...

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 | https://just-dice.com/ <-- Bitcoin gambling done right!
1397751549
Hero Member
*
Offline Offline

Posts: 1397751549

View Profile Personal Message (Offline)

Ignore
1397751549
Reply with quote  #2

1397751549
Report to moderator
1397751549
Hero Member
*
Offline Offline

Posts: 1397751549

View Profile Personal Message (Offline)

Ignore
1397751549
Reply with quote  #2

1397751549
Report to moderator
The Latest in ASIC Scrypt Miners. FREE Same-Day Shipping.
GAWMiners.com - Promo Code: FREESHIPPING
Mining Made Easy
For Everyone

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

Posts: 1397751549

View Profile Personal Message (Offline)

Ignore
1397751549
Reply with quote  #2

1397751549
Report to moderator
1397751549
Hero Member
*
Offline Offline

Posts: 1397751549

View Profile Personal Message (Offline)

Ignore
1397751549
Reply with quote  #2

1397751549
Report to moderator
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile

Ignore
July 15, 2011, 10:20:48 AM
 #402

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.
In proportional they would get paid as soon as the next block is found...

In proportional if you have a bad luck streak you get paid less. Fullstop. In SMPPS if you have a bad luck streak you might be able to recover a part.
Sukrim
Hero Member
*****
Offline Offline

Activity: 994


View Profile

Ignore
July 15, 2011, 10:23:57 AM
 #403

In proportional if you have a bad luck streak you get paid less. Fullstop. In SMPPS if you have a bad luck streak you might be able to recover a part.
In proportional (or PPLNS for that matter) if you had a bad luck streak 2 weeks ago and now have good luck, you earn more. In SMPPS you are dependent on the whole payout history of the pool since it was started if you get paid at all for your shares.

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 | https://just-dice.com/ <-- Bitcoin gambling done right!
luffy
Hero Member
*****
Offline Offline

Activity: 560



View Profile

Ignore
July 15, 2011, 11:46:08 AM
 #404

i think in SMPPS you get payed eventually when the luck changes from bad to good in the future? or you loose some shares for good?
 i am confused!

BTC S.E.B.
Simple Easy Beautiful
Sukrim
Hero Member
*****
Offline Offline

Activity: 994


View Profile

Ignore
July 15, 2011, 11:57:15 AM
 #405

You should get paid eventually. If however a lot of people leave the pool it will get very hard (and very expensive...) for the remaining ones to pay the depts from the past.

With round-based payouts you have much higher variance than PPS, but you're not depending on what happened before that round (in SMPPS in essence the "round" goes on forever).

Since it can be expected that a lot of people might quit mining when the payout per block gets cut in half, if a SMPPS pool at that point of time has a big dept towards it's miners from bad luck, it will take a REALLY long time until that is being repaid (or it might not be repaid at all - I would strongly recommend to start at 0 depts/balance after each payout split with SMPPS, as you need 100% more luck to pay past shares.)

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 | https://just-dice.com/ <-- Bitcoin gambling done right!
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile

Ignore
July 15, 2011, 12:05:38 PM
 #406

You could make it either way, but honestly I would make it so it does not remembers negative strikes, because otherwise it will stop newcomers from joining the pool. At some point the pool should almost always have a positive credit and rarely touch 0, because variance should even out.
Sukrim
Hero Member
*****
Offline Offline

Activity: 994


View Profile

Ignore
July 15, 2011, 12:30:55 PM
 #407

How would you pay out on bad luck strikes then?

pseudocode:
IF round_shares > difficulty
    pay proportionally
ELSE
    pay per share

?
This would mean you would ALWAYS win as a pool operator and otherwise it would be like proportional...

Please explain how this should work "so it does not remembers negative strikes"

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 | https://just-dice.com/ <-- Bitcoin gambling done right!
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile

Ignore
July 15, 2011, 12:48:28 PM
 #408

The way I understand SMPPS from reading here: http://eligius.st/wiki/index.php/Shared_Maximum_PPS
and from talking with luke-jr and reading some of his other posts...

SMPPS does not "carry debt". If/when the scenario rises that the total payout exceeds the block income plus the reserve funds, then the pool simply divides the block income plus the reserve by however many shares there were that round. This leads to a situation where the SMPPS shares are worth less than their advertised price. But, that is all. When the next round starts the the pool has 0 reserves and 0 debt.

The key part to this is the last part of luke-jr's pseudo code:

Code:
else:
   Pay each miner PPSamount / idealPayTotal * availableFunds
 

Nowhere in there does it mention "remembering" the difference between the ideal payout and the realized payout. It simply switch to "proportional" over the total available funds. So, technically speaking, unless the reserve fund is 0 when the payout exceeds the income, it never does true proportional.

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

Activity: 994


View Profile

Ignore
July 15, 2011, 02:24:55 PM
 #409

Ah ok, then I must have misread that part or it was changed since I first took a look at it...

All in all then the pool might just pay less than PPS on unlucky rounds or PPS on all other rounds - seems like a really bad deal to mine there, if pool funds are low! Thanks for the heads-up!

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 | https://just-dice.com/ <-- Bitcoin gambling done right!
Luke-Jr
Hero Member
*****
Online Online

Activity: 1204



View Profile

Ignore
July 15, 2011, 02:56:16 PM
 #410

SMPPS does not "carry debt". If/when the scenario rises that the total payout exceeds the block income plus the reserve funds, then the pool simply divides the block income plus the reserve by however many shares there were that round.
While it doesn't carry debt (because it never rewards more than it has), it does remember the difference, and try to make it up in the future.

zoro
Full Member
***
Offline Offline

Activity: 227


View Profile

Ignore
July 15, 2011, 02:58:59 PM
 #411

wow! 140GH! with 100GH we have 1 block/day. then prop is working just fine!
i would say to monitor the pool behavior for a while before any changes are made Smiley

"killer app" of BTC = MasterCoin https://bitcointalk.org/index.php?topic=265488.0Mastercoin(A new protocol layer on top of Bitcoin)
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile

Ignore
July 15, 2011, 04:03:58 PM
 #412

wow! 140GH! with 100GH we have 1 block/day. then prop is working just fine!
i would say to monitor the pool behavior for a while before any changes are made Smiley

The problem is that a lot of the miners will go away when the block becomes too long, as had happened in the 10th round. I am waiting for the changes to be implemented to return to the pool.

(I wish I had changed so quick because I missed the quick round and went to BTCGuild that had a horrible luck strike. Oh well.)
owowo
Jr. Member
*
Offline Offline

Activity: 43


View Profile

Ignore
July 15, 2011, 06:05:47 PM
 #413

yes, my wifi-through.concrete.floor connection broke broke about one our before we found no. 10 and i even missed no.11 Sad

how about let the user choose between prop and smpps, like on deepbit.
OldChap
Newbie
*
Offline Offline

Activity: 27


View Profile

Ignore
July 15, 2011, 07:22:46 PM
 #414

Alternate to proportional need not be non-proportional

Maybe leave things just as they are  ...BUT...  report the Round....   .Shares.....Difficulty.....Duration.....Hashrate info from 24 hours ago

Alternatively

report total shares so far this week and make the distribution at week end when all the round info could be published too

Just thinking aloud here and wondering if all pool's reports are similar just because it started that way and became the norm? sort of making everyone Hashing lemmings
lowentropy
Member
**
Offline Offline

Activity: 84


View Profile WWW

Ignore
July 15, 2011, 07:30:46 PM
 #415

While it doesn't carry debt (because it never rewards more than it has), it does remember the difference, and try to make it up in the future.
Can you clarify? How can it try to make up the difference in the future if it doesn't remember the debt? Thanks.

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>
Luke-Jr
Hero Member
*****
Online Online

Activity: 1204



View Profile

Ignore
July 15, 2011, 07:51:00 PM
 #416

While it doesn't carry debt (because it never rewards more than it has), it does remember the difference, and try to make it up in the future.
Can you clarify? How can it try to make up the difference in the future if it doesn't remember the debt? Thanks.
It remembers the difference, but it isn't a debt as nothing is considered due or owed.

fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW

Ignore
July 15, 2011, 08:49:04 PM
 #417

Quote
It remembers the difference, but it isn't a debt as nothing is considered due or owed.
Isn't that just arguing semantics?

Quote
Nowhere in there does it mention "remembering" the difference between the ideal payout and the realized payout.
It mentions it with "TotalMinerWork" and "TotalPaid" which are long-term values, lasting during the existence of your pool. After paying proportionally, TotalPaid increases but not enough to match TotalMinerWork, so the next round it will attempt again to make all the miners whole.

SMPPS and its variations suffer from long-term block withholding attacks, and will never recover from them unless the pool-op uses their fees to re-balance the coffers, or uses Generation Fees if they are enough.

Here's a variation that is at least partially immune to block withholding, and is simple to implement. I'm sure it was already mentioned in this thread:

On Valid Share: Add share to database, with values like (user_id, datetime, round, difficulty, value, paid). Value is the current PPS value (50 / Difficulty if the pool takes no fees). paid is False initially.

round and difficulty are for future-proofing, like handling Generation Fees. If the exact value cannot be determined at time of submittal, it can later (at end of round) be calculated from round and difficulty.

On Round End: Select all shares from the database where paid is False, sorted from oldest to newest. Using available pool funds, pay each share in full from oldest to newest, marking paid as you go, and stop when no more funds are available.

OR: Select all shares from the current round, pay in full from oldest to newest with half of the available funds. Repeat with all unpaid shares with the remaining funds.


It's simple from a coding perspective, and would result in less chance of making a mistake because you are keeping a log of all paid and unpaid shares (which you could even publish). You could even switch schemes at a later date, and still pay people fairly because you have a record of all their shares.

From a miner's perspective, it's simple: "You earn X amount of BTC per share, and get paid when funds are available."

And for the nosy miners who want more details: "Shares are paid out from oldest to newest, so you eventually get paid no matter what."

The alternative I mentioned above (in OR) might be preferred if people fear that they won't be paid soon enough for the work they are doing during the current round. The downside is that it does not discourage block withholding attacks, because everyone, including the attackers, get paid eventually. Block withholding will make payments take longer, so it's still affected by them but not in a way that starves the miners of income.

Luke-Jr
Hero Member
*****
Online Online

Activity: 1204



View Profile

Ignore
July 15, 2011, 08:58:51 PM
 #418

Quote
It remembers the difference, but it isn't a debt as nothing is considered due or owed.
Isn't that just arguing semantics?
It's important semantics. If people think it's debt, they will demand to be paid it. Since it's not debt, per system design, it's important that miners understand it so they're not surprised when/if they never get it.

SMPPS and its variations suffer from long-term block withholding attacks, and will never recover from them unless the pool-op uses their fees to re-balance the coffers, or uses Generation Fees if they are enough.
All reward systems suffer from block withholding in different ways. With SMPPS, it affects all the miners more or less equally.

Here's a variation that is at least partially immune to block withholding, and is simple to implement. I'm sure it was already mentioned in this thread:
Tracking every single share is basically absurd.

fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW

Ignore
July 15, 2011, 09:46:52 PM
 #419

Quote
Tracking every single share is basically absurd.
Would you mind elaborating? I was under the impression pushpoold stored all submissions to its database anyway, and SQL servers will handle hundreds of millions of rows, if not more. If performance begins to degrade, you can just dump all the paid shares to a separate table or a backup database and remove them from the live database.


1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile

Ignore
July 16, 2011, 09:10:02 PM
 #420

Thanks everyone for your input. We are currently working on running some simulations to determine the behavior of the various PPS methods described above.

We hope to have some feedback shortly, but in the mean-time we are still very much interested in everyone's opinions.

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