Quote from: mueslo on August 23, 2013, 03:20:36 PM

What makes more sense: when a block is found by the pool itself (and not the whole network), all previous shares are reset to zero and the reward of that block is distributed among shares. I'm guessing you want the latter?

The fact is I really don't know how it works right now. But, when I am talking about block change I mean block change for the network. I am starting to realize we are all working under a lot of personal assumptions about this because we don't know for sure what the reward system is. My assumption, and the one I've been arguing from (I hope not for nothing, but at least it would be settled), is that we get paid per block per shares that we have for that block.

Quote

But anyway, if you want to actually simulate this, you can no longer calculate the time when a block is found, because then it could happen that the pool finds a block without any share actually having been submitted

This could happen, yes (very very unlikely but possible). But, you can simulate it. That could happen in my simulation and I believe it would handle it correctly.

If my reward is set to 100, and neither worker got a share in time , it would simply pay 0/100 (0) of the reward to each.

We can continue to argue weather my system is correct in a proportional-per-block scenario, but we still aren't sure if that is the case anymore, so I'm just holding out to hear the scoop on that.

Part of me hopes I was dead wrong and H20 is using some other reward system so we can finally put it to bed.

Quote from: mueslo on August 23, 2013, 03:20:36 PM

At the end of every block? That wouldn't make much sense though (there is a big chance of loss for the pool operator if the network suddenly becomes fast).

It shouldn't effect the pool as a whole. The pool as a whole would still solve just as many blocks, it should only affect the shares within the pool.