Bitcoin Forum
May 04, 2024, 08:55:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Adaptive Pay per share  (Read 720 times)
AlephconZero (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
April 15, 2014, 07:29:07 PM
 #1

Why not?


Removal of PPS based on period of bad luck


Why do not authomatize the PPS DURING PERIOD OF BAD POOL LUCK. For users who are not aware, the PPS method means the pool actively loses money during bad luck, with the assumption that the long run will make the pool significantly more. This has been the case since inception, but there is another risk associated with PPS in the form of the hot wallet. Pools keep a hot wallet balance which is used to pay miners when they request payouts.

Due to PPS being unrelated to blocks being solved, a PPS pool is required to keep the hot wallet balance significantly higher than a non-PPS pool. This means the risk of an attack on the pool draining the hot wallet is significantly greater. With the value of Bitcoins these days, paired with the shrinking of pools as larger private farms coming online, the variance of PPS (on the pool side) has become too significant, and lead to high risk of looosing higher performances.

PPLNS is a better deal for miners in the long run.
1714856119
Hero Member
*
Offline Offline

Posts: 1714856119

View Profile Personal Message (Offline)

Ignore
1714856119
Reply with quote  #2

1714856119
Report to moderator
1714856119
Hero Member
*
Offline Offline

Posts: 1714856119

View Profile Personal Message (Offline)

Ignore
1714856119
Reply with quote  #2

1714856119
Report to moderator
"Bitcoin: mining our own business since 2009" -- Pieter Wuille
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714856119
Hero Member
*
Offline Offline

Posts: 1714856119

View Profile Personal Message (Offline)

Ignore
1714856119
Reply with quote  #2

1714856119
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
April 15, 2014, 07:52:06 PM
Last edit: April 15, 2014, 11:50:47 PM by TierNolan
 #2

PPLNS is a better deal for miners in the long run.

Eligius has a compromise system.  They payout on a pay per share basis, but only if they have funds available.

When a share is submitted, it is placed in a stack.  This means that newest shares are paid first.

When a block is found, the money is used to pay shares in the stack.

No share is ever paid twice but the pool can never run out of money.

This means that expected value is less than the "fair" amount.  You get paid p * (fair amount), but p < 1, since some shares never get paid.  Assuming there is a reasonable amount of funds in the pool, then p is probably pretty close to 1 anyway.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
AlephconZero (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
April 15, 2014, 08:02:05 PM
 #3

What about put an slightly high difficulties, maybe 2...
gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
April 15, 2014, 11:07:34 PM
 #4

Eligius' approach doesn't remove as much variance as it could, however.  The problem is that no miner has an actual expected return of the PPS rate because of blocks that fall out of the chain, withholding, etc. As a result miners who are mining when the pool is lucky get overpaid (full PPS), and ones mining when the pool is unlucky get underpaid (pool will never make it back to them).

The approach used by Eligius could be improved by measuring the difference between actual recent income in a window and PPS and coming up with an expected true reward coefficient C.  Then credit the share stack PPS*C, and credit in a second share stack PPS*(1-C), the second share stack is only ever paid in the unlikely event that the first share stack is paid completely.

But I'm not really sure if that payment mechanism really makes that much sense to continue developing simply because it requires a fair amount of storage and computation, and results in payments happening months or years later, which complicates key management.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!