Bitcoin Forum
April 26, 2024, 11:59:07 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: CPPSRB (or similar) without short round buffer?  (Read 1404 times)
roy7 (OP)
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
April 17, 2013, 06:20:22 AM
 #1

I've searched the threads I can find but it seems just a given in these methods that on a short round, if there is no backlog to pay, the pool keeps the extra shares and uses them to pay out later when a long round eventually pops up. I'm wondering why that is. If you have a short round, and there's no backlog, why not pay out the extra coins to the current shareholders? That seems more intuitive to me. Miners working right now might not be mining down the road, so I'm not sure why they should be reducing someone else's future payment delay during a long block? It makes sense perhaps if you had a static group of miners and wanted to reduce variance of your ongoing income stream. But miners come and go...

Curious as to anyone's thoughts on this.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714132747
Hero Member
*
Offline Offline

Posts: 1714132747

View Profile Personal Message (Offline)

Ignore
1714132747
Reply with quote  #2

1714132747
Report to moderator
kinlo
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250


Pool operator of Triplemining.com


View Profile
April 19, 2013, 09:41:32 AM
 #2

because you WILL have long rounds too, and if you gave the coins away, then you can't pay people for the long rounds.

If you want to give people the extra's if the rounds are short, use the PPLNS payout system....
purelithium
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
April 19, 2013, 12:55:09 PM
 #3

because you WILL have long rounds too, and if you gave the coins away, then you can't pay people for the long rounds.


/thread.

Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
roy7 (OP)
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
April 19, 2013, 12:58:54 PM
 #4

Well, a long round now will be paid off by a short round later. By not saving some short round in the past to pay a future long round, it does mean the next long round will take longer to pay. But for people who mine long term it should even out, since whenever the pool is caught up you get paid more in the short rounds.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
April 19, 2013, 01:13:31 PM
Last edit: April 19, 2013, 01:58:28 PM by organofcorti
 #5

Well, a long round now will be paid off by a short round later. By not saving some short round in the past to pay a future long round, it does mean the next long round will take longer to pay. But for people who mine long term it should even out, since whenever the pool is caught up you get paid more in the short rounds.

Your suggestion is that the pool should always be in negative buffer. This means that, on average, it will take a while longer for you to be paid than at other pools. Some info on the related SMPPS reward method here and here .

Also, if you pay out extra coins for short rounds, you are in essence proposing a proportional payment method.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
roy7 (OP)
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
April 19, 2013, 01:57:13 PM
 #6

Also, if you pay out extra coins for short rounds, you are in essence proposing a proportional payment method.

Yes basically. CPPSRB for long rounds, proportional in short rounds. I'll re-think that though. DGM is great mathematically, but I'm not sure about my ability to reasonably implement it and I'd also set the parameter to zero that accounts for operator variance, as I'm working on a pool for fun and not to pay miners out of my pocket like inevitably bankrupt PPS pools. Smiley

I do intend to pay all transaction fees to miners, but shares are only credited d/D of the base new block reward (without transaction fees). So the transaction fees are "extra" (fractional) coins to pay towards the backlog, or extra pay in short rounds. I wonder if the average transaction fees are enough to eliminate long-term expected negative buffers, though. I was a math minor in college ~18 years ago, but I don't retain anything useful compared to Meni.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
April 19, 2013, 02:00:54 PM
 #7

Also, if you pay out extra coins for short rounds, you are in essence proposing a proportional payment method.

Yes basically. CPPSRB for long rounds, proportional in short rounds. I'll re-think that though. DGM is great mathematically, but I'm not sure about my ability to reasonably implement it and I'd also set the parameter to zero that accounts for operator variance, as I'm working on a pool for fun and not to pay miners out of my pocket like inevitably bankrupt PPS pools. Smiley

I do intend to pay all transaction fees to miners, but shares are only credited d/D of the base new block reward (without transaction fees). So the transaction fees are "extra" (fractional) coins to pay towards the backlog, or extra pay in short rounds. I wonder if the average transaction fees are enough to eliminate long-term expected negative buffers, though. I was a math minor in college ~18 years ago, but I don't retain anything useful compared to Meni.

PPLNS might be a solution if you don't feel confident deploying DGM  - although Meni has been very helpful to pool ops that have used DGM. What you really don't want to do is spend time on developing a new reward method. There's a good chance it will be exploitable from a direction you haven't seen. Why not use one of the provably fair methods?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
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!