Quote from: BetKing.io on October 19, 2016, 01:26:49 PM

Quote from: RHavar on October 19, 2016, 01:15:16 PM

Quote from: fluffypony on October 19, 2016, 06:01:02 AM

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.

::sigh::

That's not what a replayable log is, at all. A replayable log is logging all the individual events (e.g. bets, investments and divestments), in such a way that if you found a mistake had occurred (or in this case, fraud) you could fix the mistake (in this case, delete the bets) then replay everything so the investors balance is exactly is if the fraud never occurred in the first place.

It's actually just a good practice to be in, when ever I mutate state I *always* store the cause of it. (e.g. if someone transfers money, I log an event of the transfer. If someone claims the faucet, I store the details of that, if someone invests I store a record of it (and things like how much the bankroll was before they invested) etc).

And probably the other mistake people make, is over-constraining their database to not allow negative values. e.g. While a user balance never should be negative, the system should support it as cases like this might cause some accounts to legitimately be negative (them withdrawing gains they shouldn't have) or even deposits reverting after a blockchain reorg etc.

It's great for a disaster recovery situation like this, and it's great from an audibility perspective

Exactly, see http://martinfowler.com/eaaDev/EventSourcing.html

Note that even if you don't follow strict event sourcing best practices you should still have a log of everything anyway so that you can replay, just takes more effort. Surely each bet/invest/divest actoin must have a timestamp on his MySql rows?

Guys, you don't know our system design, you don't know our architecture. Even if you did, you can't possibly have all the facts of the matter. The continuous string of commentary is entirely pointless - the decision is not going to be made again, we've already moved past it.

And yes, we have timestamped logs for every single action, every single bet, every single investor credit, every single investor debit.