How is the code exploitive? I am new to this like a lot of others too.
It requires quite an in-depth understanding of moneypot source to understand. But the high level of it is that money pot's game_end event was leaking information (or more precisely the lack of money pot's game_end event) which could be abused by taking advantage of dynamically moving the autocashout amounts (something that is now disabled).
Because it was so timing sensitive, the code had to be rather complex taking into consideration network latency to decide how and when to act.
Let me see if I can explain it differently.
As a round progresses, the server sends regular 'tick' messages to the client, saying:
"1.10x and the game didn't crash yet",
"1.20x and the game didn't crash yet",
etc.
and the client fills in the gaps in between, making the number count up smoothly, animating the chart, etc.
The exploit code would set the auto-cashout at 1.11x, and wait for a short time. Just before the "1.20x and ..." message was due, it would update its auto-cashout to 1.21x, and so on. It was changing the auto-cashout just before each 'tick' was due, changing the auto-cashout to just after the next tick's multiplier.
When the game eventually crashed (at 1.27x, say), the server would check the auto-cashout, see that foo had his set to 1.21x, and pay him accordingly.
The problem is that the server only checks for auto-cashout points at each tick. If you have one set at 1.11x, it doesn't get paid out until the next tick (because there is really nothing between the ticks - the steady payout multiplier increase is an illusion presented by the client), at 1.20x. So you could move it up to 1.21x just before that tick.
The fix is to prevent players from changing their auto-cashout point. That's not a problem because the feature was never published anyway. You would never have even known there was the possibility of changing your auto-cashout point mid game unless you had read the source code.
