4 ms·

Bank 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 n

Bank 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 ago
That'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 ago
If I'm not mistaken, an eventually consistent database must also guarantee, well, eventual consistency.
- aredridel 13y ago
  Sure! 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 ago
    The 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 ago
  The 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.
  - nevi-me 13y ago
    But debits and credits do not use multiplication nor division, so for those transactions the order doesn't matter.
    - jamesaguilar 13y ago
      If eventually consistent databases stored pending operations rather than pending values, this would matter. Unfortunately, they actually tend to be value based. So when you perform an operation on stale data, either the new operation will be lost, or the old one, depending on the implementation.

mbreese 13y ago

That'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 ago

If I'm not mistaken, an eventually consistent database must also guarantee, well, eventual consistency.

aredridel 13y ago
Sure! 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 ago
  The 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 ago
The 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.
- nevi-me 13y ago
  But debits and credits do not use multiplication nor division, so for those transactions the order doesn't matter.
  - jamesaguilar 13y ago
    If eventually consistent databases stored pending operations rather than pending values, this would matter. Unfortunately, they actually tend to be value based. So when you perform an operation on stale data, either the new operation will be lost, or the old one, depending on the implementation.