Bitcoin Forum

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.

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

/thread.

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  (http://organofcorti.blogspot.com/2012/03/31-rise-and-fall-of-arsbitcoincom.html) and  here  (http://organofcorti.blogspot.com/2012/04/32-risks-of-smpps.html).

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

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?