5 ms·
That's because banks employ systems that guard against this kind of elementary error. It's called transactions with ACID guarantees. Bank systems are often not
by patio11 13y ago
That's because banks employ systems that guard against this kind of elementary error. It's called transactions with ACID guarantees.
Bank systems are often not, in fact, ACID. Think of how many billions of transactions are processed in end-of-the-day batch runs, for example. Overdrafting is not only not impossible, it is a ludicrously profitable feature of the system.
How is this secure? Velocity limits, sophisticated anti-fraud systems, acceptable losses, and, as a bit of a by-the-way, the fact that people who make a habit of defrauding banks generally have a few weeks prior to being woken up by very serious men with guns.
- rdtsc 13y agoIt is interesting because the transaction log inconsistencies can often be resolved technically and because of the regulatory framework. Overdrafts can be "solved" in business sense. Now imagine something like an bitcoin exchange and bitcoin transaction log. Transaction errors cannot be fixed easily. So overdrafting an account means never getting the money back. There a single account would need to have ACID properties in way. It seems ability to deal with and tolerate data conflicts and inconsistencies is different for each business. There was some interest in CRTDs (data types that can automatically converge after a conflict occurs, like imagine a max() function or a set union operation) but still means shortly there could be an inconsistency in the system and sometimes that can be exploited and is just not an option.
- Karellen 13y agoBank systems are ACID. They're often not immediate, using batch runs as you say, but the databases the batch runs work on are definitely ACID. The problem is not necessarily with overdrafts, as you suggest, but - as the article says - with race conditions between multiple readers/writers causing two near-simultaneous withdrawls to only make a single debit to the source account, while crediting both destination accounts. Note that this could lead to unexpected overdrafts being noticed later, if the exchange also wrote a consistent log of all transactions, and attempted to reconcile the log with the real-time balances periodically (e.g. on a daily basis), but it's not clear if they even did that. (Although I might be missing something)
- mbreese 13y agoThat's why banks have an available balance and a posted balance. One is the best available estimate of how much money you can spend. The other is the reconciled balance after transactions have been posted. It would have been possible for the exchanges to have used a NoSQL db with this strategy, but they didn't. They should have been keeping transaction logs and reconciling balances, but they didn't. While, I'm no fan of MongoDB, it isn't really their fault. These exchanges were designed by people who didn't know any better.
- pron 13y agoIf I'm not mistaken, an eventually consistent database must also guarantee, well, eventual consistency.
- aredridel 13y agoSure! All nodes will be consistent in that your balance is what they all think it is, and that the attacker's balance reflects the attack. But unless those actions are coupled in a transaction, each account may not be consistent with the other.
- google-serf 13y agoThe problem is that while overdraft is very profitable for the bank; you acquire a legal liability to pay back that debt. Overdraft cannot be offered in a non fractional exchange and the exchange can't find you if you take more than your balance. Money leaving the exchange must be reconciled with holdings or they are insolvent. What we may see is blockchain denoted exchange holdings; your exchange wallet is unique and publically verifiable (only the exchange holds the keys). You could verify with balance with the address and all trades are performed on blockchain. Bitcoin would be inappropriate for this with its long confirm times but a newer faster scrypt or primecoin variant might do it. Exciting times!
- Alex3917 13y agoThe problem is that eventual consistency doesn't mean eventual correctness. The basic issue is that math usually only works if you do it in the correct order, e.g. (X+2)5 != (X5)+2. And if you're using a document store to do mathematical transactions then you're not guaranteed that they execute in the correct order, all that you're guaranteed is that all the nodes will eventually be the same in your database.
- mriou 13y agoBanks are made of a mess of different systems. Some are locally ACID, but overall reconciliation and compensation are what keeps it all together. Regardless, this has little to do with banking. The systems are too widely different to be compared productively. The only conclusion you can get from this (marketing) story is that when you have an eventually consistent system, you will need occasional distributed locking. Cassandra often comes in pair with ZooKeeper. The other conclusion is that no matter how trivial they sound, distributed transactional systems are far from trivial.
- jeffdavis 13y agoACID would have solved this problem though, right? ACID is simpler to reason about. If there is a strong justification for abandoning it, and enough expertise to still make the system work, then fine. But I doubt they had either the justification (I assume their transaction volume could be easily handled with a SQL system) or the expertise. I'm bothered that MongoDB strives to make people feel comfortable abandoning ACID who clearly don't understand what they are doing.