In fact, a colluding delegate could just ignore transactions when they know they have a loser. It doesn't even have to be a missed block. Wouldn't this be simple to do ? So you now have to expect transactions to go in certain blocks and figure out all the heuristics for this? Isn't that what is required for bytemaster's missed blocks == house rake approach to work ?
It really isn't missed blocks, it is just not accepting transactions and pushing them off to next block. This is a harder attack to discover unless you start timestamping transactions etc. I think this might be required to detect this attack ?
You can keep the "winning/loosing" a secret until after the ticket has been included. So this is not an issue.
You can reveal winning/losing after ticket has been included, but that requires extra blocks which adds latency in the game if I understand correctly. Ideally gaming transaction is put on same block as RNG revelation. Otherwise we add 10 seconds to every game round.
Yes, But I think 10s latency is acceptable for most of the chance games. For real time game, hmm. I think it's still a long way to go.
BTW, for some counterparty betting chance games, they may not depend on any 3rd RNG, including the one from DPOS.