Quote from: jtpeters on March 04, 2014, 05:33:59 PM

Quote from: dooglus on March 04, 2014, 05:22:14 PM

Quote from: busoni on March 04, 2014, 08:31:32 AM

The next thing that will be done--before markets are unfrozen--is a daemon will be created that continually monitors for negative balances and freezes any account with a negative balance

This isn't the right way to fix the problem.

What you need to do is to make sure that users aren't allowed to do two balance-affecting things at the same time. Otherwise they'll just find another way to cheat you.

Make "check balance" and "reduce balance" atomic.

Checking for negative balances isn't the answer. Suppose I have 30 BTC and try to very quickly withdraw 10 BTC twice. Both "check balance" calls see I have 30 BTC, which is enough. Both "reduce balance" calls set my balance to 20 BTC. Then you send me two separate 10 BTC payments, my balance has never been negative, and I'm 10 BTC up on the deal. You need to make sure that the "check balance" and "update balance" happen without anything else relating to that user happen between them.

This is a security issue that has been documented for weeks. OP just didn't keep up with security patches.

How is this a security vulnerability that has been known for weeks? This seems more like a code issue and race conditions rather than something that has only been around for weeks. The solution is to push all withdrawals to a pendingwithdrawals table that the engine then hits and deducts balance, this way even if the user tries to game the system and has say 5 withdrawals entered at the same time, those withdrawals are in a "pending" table, when the engine grabs them it then checks balances again sequentially on those rows and any withdrawal that the user does not have enough funds for is set to canceled. This is the type of thing that should be done with ALL user input, orders, cancel orders, etc.