Is the 'p' used here '1.0/D' or is it 'd/D' (where d is user's difficulty of submitted share). If it's 'd' how is it affected if a user has their difficulty changed part way through a block? Is it the 'd' for the most recent share submission?

Thanks, I assume the 'r' used in that calculation should be calculated using a 'p' adjusted for the difficulty of the share that solved the block too?

In any case where f>=0, the operator will not be paying out of his own funds, is that accurate? I think I was misunderstanding "operator variance" as meaning the operator may be paying money out of his own funds like PPS in long rounds. Which I'm not willing to do. However, if it is simply variance in how much the operator earns without ever going negative, that's a totally different situation. I wouldn't mind my earnings (as an operator) going all over the place as long as the pool cannot ever go bankrupt in terms of payouts to miners like PPS.

Did you ever write this up someplace?

Yeah, it's discussed in AoBPMRS.

Yes.

It doesn't need to be but that generally gives a reasonable tradeoff between variance and maturity time. X in PPLNS is in some ways analogous to approximately c/(1-o).

It wasn't designed to work with variable c; I think we could make it happen if we change the way some things are parameterized, but it's easier to vary f (make it 0 for the high-difficulty-share miners, and slightly higher for the low-difficulty shares).

Leaving the score alone won't work.

You could add to the worker's score in a way that compensates for the lost payment, but that is more complicated. It is simpler to keep a record for each miner of the total deferred payment, and when it is high enough make the physical payment via a normal transaction. Deferred payments will be kept in a designated address in your control.

It's even simpler than that - you don't need to set S=S/o. The score will remain in its reduced state and only the actual payment will be cancelled, and if you pay in the coinbase this happens naturally when the block is orphaned.

I can see why it is intuitive to treat orphaned block as if they never happened - thus cancelling S=S*o - but the method invariant is based on the assumption that a share has a probability of d/D to be a block. If orphans exist this is no longer the case, shares actually have a lower chance of becoming a valid block. If orphans are ignored completely, the operator will pay out more than he should (the block rewards he actually receives are lower than the method assumes). I've done the math and if you simply cancel the payment specified for the orphan blocks, everything is just right. This assumes, however, that every block, once received by the pool, has the same chance to become an orphan.

A tricky part is how to combine this with the dust payments mentioned earlier. You can no longer rely on the network to cancel the orphan payments - you'll need to actually remember for each worker the reward per specific block, and if a block becomes an orphan remove that record yourself.

I think I'll just take your word for it and run with it. As they said in Star Trek II, "Yours is the superior intellect."

Shares submitted after the orphan will be worth more than those submitted before, and this is proper.

The orphan did happen and this is information that needs to be taken into account. The orphan blocks are not in addition to the valid blocks - they are instead, some of the blocks which should have been valid end up orphans instead. The correct comparison is not orphan vs. no block, but rather orphan vs. valid block.

When a block is found, all past shares have a chance to get a payday if it ends up valid. The cost of this chance at payment is the score reduction - even if, contingently, it ends up an orphan. Later shares never had a chance to profit from the block, and thus don't get their scores reduced for it.

This is similar to the situation with shares in general in a pool - when you submit a share, you are rewarded even if the particular share was of no use, because in finding a share you had a chance to benefit the pool - and you get an expected reward equal to your expected contribution.

Right. In practice you could trim scores which are below a very low threshold.

It seems you are suggesting that rescaling on every share is easier than rescaling once in a while, I don't see why.
I do recommend logs, they're less intuitive but more robust and probably less resource intensive.

S/s is not the expected payout from the next block. S/s (or more accurately (1-f)*(1-c)*S/s, accounting for fees) is what you asked about just now - the expected total eventual payout for already submitted shares.

The expected payout for the next block is S/s * (1 - c/(1-o+co)) * (1-f).

TLDR: If you jump down to Edit #2, I figured it out.


This is giving me values about half of the actual amount paid in the blocks. To use some real numbers on one specific block, here is my amount paid out formula. I am re-scaling $s to 1 every share. So it is $s=$s*$r in the figures below.


If I also calculate the estimated payout for the next block at the same time, I get (leaving outs since I re-scale to 1 constantly.)


For S=12.932020560171, r=1.0000315757467, c=.03, f=0.0, o=.97, p=3.2552316167526E-5, s=1.0000315757467. The estimated equation reduces to 12.932020560171 * 0.4923857868 which is why it's about half. (With re-scaling every share, the payouts are extremely similar to the actual score value itself.)

I think I have the math coded properly. So either I misunderstand what "expected payout for next block" means or I have a blatant bug in how I'm coding the formula. Assuming formula is correct.

(To try and get a handle on how DGM operates, I'm using my share database to recreate "what would have happened" with DGM from start to finish. Since I'm only doing private testing, my test data is limited with about a week of mining and 3 blocks found, on an alt coin. Maybe the sample size is too small. 99K shares recorded with average block difficulty 36K, the block difficulty changes every block.)

Edit: Just occurred to me. Is the expected payout for next block given above if the miner stopped mining? So on average, D shares from now the payout to the miner would of course be much lower than the numbers I'm seeing (since the miner in my data sample kept mining away).

Edit #2: Yes that's it. I should have worked on it more before posting. Sorry for all the noise. It's spot on.

I injected an extra 41000 shares of work on a 41000 difficulty block into my database, and then injected a new "found share".

Before these changes, up to the final point in time for a worker (not the one listed above):
"Expected remaining total payout 6.1845766103505, next block pays 3.0451976203249"

After my artificial data injection,

Block Found: (score 3.1393789900256) pays out: 3.0451255771104

Nailed it within .00008. And I bet that's because there actually were a few thousand shares in the database after the last real block I left alone (so it was a slightly long round I created). So if someone stops mining, I can tell them their expected remaining total payout and their expected payout in the next block too. Awesome.