Quote from: purelithium on September 12, 2013, 12:07:43 AM

Quote from: Lucko on September 11, 2013, 11:31:11 PM

DMG pays more then pool makes

Not true at all, it pays out much less than the pool makes on a long round, but more than the pool makes on a short round. That's what evens it out, not orphaned blocks.

I wasn't talking about that... I was talking about math that calculate DMG payment... I think this post explains a lot more then I could.

Quote from: doublec on June 02, 2013, 12:10:51 AM

Quote from: redtwitz on June 01, 2013, 04:44:04 PM

Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful Wink

) and the pool finds a block that is later orphaned, the payments of the next valid block will be lower than they would be if the orphaned block never existed.

The effect of the payments of the next valid block will depend on if the orphan block is short or long. In the longer term this effect is minimized and the the general cost to the miner is the percentage of orphan blocks the pool gets.

According to Meni Rosenfeld, the DGM creator, the scores should not be adjusted if an orphan occurs. There's a discussion in the DGM thread about this and you should raise any questions you have there. Here's what Meni says:

Quote

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.

And later in the thread:

Quote

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.

It would be nice to have a method that could adjust for orphan blocks and 'make up' payment for them but it's not possible since we can't predict the probability of a block accurately in the presence of orphans. The pool doesn't have a way to 'make up' the cost of orphans and pass that on to miners, other than increasing the fee to approximate the orphan rate. From what I can tell users prefer losing out on orphans but paying a lower fee.