not something we have looked at yet, I imagine in a few payments time we will be able to get a better idea of the average

Resets what to 0?

I think what kano is trying to say is that, since invalid block is equivalent to no block, the existence of an invalid block shouldn't affect people's scores. So in a method like proportional, people's scores shouldn't be reset to 0 for invalid blocks.

The problems with his approach are that:
1. It's more complicated to implement.
2. It doesn't matter that much in the case he is considering.
3. It assumes using the proportional method. For PPLNS it's moot since scores aren't updated upon finding blocks. For DGM it matters somewhat since scores are meaningfully updated on blocks, but as I derived some time ago, the correct way to handle this and ensure a fair reward is to update the scores on any block, even if it is invalid. But I was surprised that Graet implied that scores are reset to 0, unless I misunderstood or missing an implementation detail, this could imply an error in his DGM.

Huh, I'm not sure what's going on with regards to that at OzCoin, it was my understanding from YourBTC that we had a functionally similar DGM implementation (Although I think theirs is handled after the fact via PHP where as EMC is handled in real time, so maybe that's why it's different?)  - anyway, when there's an invalid block on EMC, things just continue as normal and your payout is calculated based on your score.  Meni and I addressed it at the time we implemented DGM - I don't see why the same wouldn't have been done on YourBTC so consequently it should be the same at OzCoin.  

While I'm speaking purely about DGM (since it's both EMC and OzCoins model), the same really applies even to a prop pool like BTC Guild Prop you are talking about.  Assuming (and maybe it's an erroneous assumption) the hashrate remains relatively constant from Block X ---- Block Y, regardless of whether or not an invalid block is between it or not, your payout is going to be the same.  

To illustrate this, say you have 10% of the pools hashrate.

Block X -----> Invalid -----> Block Y  = You receive a total of 5 BTC after the invalid goes poof and block Y is solved.

Block X -----> Block Y = You receive a total of 5 BTC.

Whether or not it's prop or DGM, it really doesn't matter.  The net effect of an invalid block is that it doesn't exist and should never have existed in the first place.. so you aren't out anything.

What I suspect some people take umbrage with is the fact that now Block X ---> Block Y appears to be X + (Invalid ---> Block Y) shares, instead of X shares.  But if the invalid block was masked (like it really should be), your shares are still X.

The thing is, with variance, there may only be a handful of shares between Invalid ---> Block Y or there may be a ton of shares.  But in the end, it will still end up at close to 0 variance, which is effectively proof that the invalid block never really existed and thus nothing was lost.

What that 2.5% "donation" or fee bought you was effectively an extra payment that you should not have received for a block that never existed.  I think maybe it set a poor precedent (or really maybe Deepbit did) in acknowledging an invalid block as a legitimate entity that a miner is somehow entitled to.

thanks Inaba , I do understand and in fact that is what we did on the pool when it was proportional

but please bear with me a monent.
When I sit here looking at poolserverj's console and see a block found message with the hash and the finders userID my pool sees a block, the bot in our irc chanel announces a block,miners go "woohoo", share count is set to 0 and a new round commenced etc.
After this "block" is announced to the network the network verifies or orphans/invalidates/<chose any other word that suits> our block depending on network criteria and others "blocks" submitted close to the same time.

Meni, i meant this bit " share count is set to 0 and a new round commenced etc."

Now I have had a discussion with someone knowledgeable about this as well and was told it couldn't have happened, but one time we saw a block "orphaned" at 8 or 9 confirmations... blocks were rare at the time and I was watching the wallet and announcing the confirmation count in IRC got to 7 went for a drink, came back and it had been orphaned- it did happen.So early payout is always a risk.

So
Actual topics covered in more detail so we dont need to keep going around in circles
1:  sorting the software to Block X ----> Invalid Block ----> Block Y as we did in the past.
2: We need to work out a way to incentivise "donations" that doesnt involve paying out at 0 confirmations maybe at 5.Realising that I do pay the server costs and would like the pool to break even oneday but also to reward and give incentive to the coders for their good work and any other bounties or dontaions to bitcoin software developers not on staff.Whilst still giving the option of 0 fee pool.
3: We do not want to put ads on the site and then offer for ppl to pay to have them removed - but always an option
4: Reintroducing TXN fees with block payouts
5: Getting massmail setup on new site. so we can inform miners of changes, planned outages etc.
6: Stabilising displayed hashrates
A lot of these are being workked on and those that arent are in a to do list
And quite a few other that i dont think it is neccesary to share at the moment - do keep an eye though, some interesting stuff coming for Ozcoin miners .

Suffice to say work is not finished and the first post in this thread is the first place I update when changes are being made

slow reply, sick kid finally sleeping
hope it helps clear the situation

What happened at BTCGuild was:
A block was "Invalid" then a VERY short block occurred after that so only the high hashers got shares in it.
Result was that everyone who hashed up to the "Invalid" who didn't have a 2.5% donation and had no shares in "Block Y" (low hash rate) got nothing for all their hashing from "Block X" to "Invalid".

Basically what it means is of course that your hashing from "Invalid" to "Block Y" determine your payout and your hashing from "Block X" to "Invalid" is ignored.
This can be the same or can be different depending on a quite a few things.
I'm not sure what effect this has on DGM.

Also from the pool point of view they are paying out extra BTC for hashing from "Block X" to "Invalid" for anyone who has >= 5% donation

Discussion for that is here:
https://bt.irlbtc.com/view/48653.0

we have maintained >200Ghash for a week
Encouraging mods to sticky us among top10

  worked

wtf, some anonymous user is mining on this pool right now @ 358.6 GH/s

http://dl.dropbox.com/u/25848420/wtf%20358ghs.png

who the hell is this?

Its not a single entity. If you choose the "private" option in your pool preferences instead of "public", you will be added to the Anonymous score.