I lost? I was invested in the roll for the entirety of that guys bets he did not make 1 bet that I wasn't apart of( From all the ones I pasted) the other 30k he won that I didn't see I may or not have been but we should be able to know since I know nearly what % of the roll i had invested before I deposited 20 hours ago. I'm not some dude trying to scam you if you look in the crypto-games thread, the support sent me a extra 81 ether 2 days ago in 1 of my withdrawals and I sent it back.
How can you claim no investors lost when, I deposited 32 Xmr and 20 hours later my Xmr is worth 15 Xmr...... I only divested and cashed out because it was evident to me he was cheating after I looked at those rolls and I somehow get punished for alerting you guys and acting in a intelligent way. I'm assuming I alerted you since I posted in chat my suspicion, then emailed support with a title Seed been hacked. Then pmed Nico with my suspicion, then I requested a withdrawal that was sent while there were no indicators of anyone aware of the hacker other than the hacker and I, also I didn't see his rolls happening, I just opened a tab saw all those bets, no bets were made after I had noticed the seed was compromised.
If all his wins were re-added to the bankroll then my funds would have been re-added to the bankroll because he did in fact win my Xmr... So since I can verify he did in fact win my Xmr and I can verify you guys did in fact add his wins back to the bankroll where does the extra Xmr he wins that were originally my investment end up?
His wins weren't re-added to the bankroll based on the prior state, they were re-added based on the state of the system at the time we were re-adding it. The state of your part of the bankroll at that time was 0, so you don't benefit from that.
Let me put it differently: you saw the errant bets and you divested and withdrew your money, in a panic and at a loss. What if the attacker had gotten away with his withdrawals, and we had to socialise the loss? Would you deposit your money back in to participate in that?
In a situation like this you, as a participant in the bankroll, have your funds invested at risk. Everyone takes the same risk, and gets the same reward. If you try and circumvent a scenario you are effectively cutting your losses, come what may, and it isn't reasonable to turn around afterwards and expect an outcome that is any different.
Look, if the $100 you lost in this scenario is completely untenable then we'll personally send you 15 XMR from the site profits.
I'd be interested in this aswell, how did you determine which investor got which part of the secured funds back once you rolledback the clearly compromised bets?
Based on the investor roll at the time of the distribution out. Because there had been users created and withdrawals / deposits processed in the meantime, we couldn't simply roll the database back.
I think probably it is added back to the investors at the time of adding back. So if someone divested, he won't get anything, but if someone invested, he would get a share of the added back amount

Yep exactly; there wasn't any other way to do that that wouldn't have added insane amounts of complexity to the process, and potentially left the data in an extremely broken state.
Yeah, that's how it sounds like. Actually when I designed the moneypot investment system, what I did was create a repayable log of all the investment/divestment/bet events for in a nightmare situation like this (or software bug) it could be replayed so investors wouldn't have made/lost money from the changes in the bankroll when a fake better (or software bug) was playing.
The situation is probably a big mess now, as some investors have lost more than they should've and others made more than they should've. And it's probably pretty likely the ones who unfairly made money have already withdrawn (?) or at the very least, will be unhappy if their balance gets put to the correct amount
We already have a replayable log (that's the point of the MySQL log after all), but we couldn't rewind the entire system. Consider, for instance, a new user that created an account and deposited funds. If we roll the system state back we would have to manually allocate all of those and manually recreate the users. And, too, consider the exact issue we've got above, where a user divested and withdrew - how do you roll that back? You can't, so you have to move forward with the system in the current state.