Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NoSQL Meets Bitcoin and Brings Down Two Exchanges

hackingdistributed.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#21

Post by aredridel »

pron wrote: post #17
Karellen wrote: post #12

Earlier quoted context omitted.

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 accou…

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

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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#22

Post by danbruc »

It's the same story over and over again. The young wild guys arrive, full of energy and ambition to make the world a better place. They throw all the ancient stuff overboard because it seems ugly and useless. Then they painfully rediscover why the ugly stuff is there and not useless at all. And after a lot of pain they finally arrive at a slightly improved version of what they threw overboard long ago, at least if they did not surrender before.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#24

Post by dnmmnd »

edwintorok wrote: post #19
ChuckMcM wrote: post #10

Its unfortunate to use the ATM example because just such an exploit was used by carders [1] to get more money out of accounts than the accounts actually had. [1] http://time.com/48344/hackers-target-atms-for-unlimited-with...

ATMs aren't as smart as the article says either: "the real code will check to see if there are sufficient funds". I noticed that (some?) ATMs around here tend to implement this flawed algorithm, paraphrasing the article: 0. database.begin() 1. mybalance = database.read("account-number") 2. newbalance = mybalance - amount 3. database.write("account-number", newbalance) 4. database.commit() 5. dispense_cash(amount) At…

Whilst that maybe the way your bank has chosen to operate, it is most certainly possible for ATMs to report a step#5 failure to the banks host which will reverse the transaction.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#25

Post by mikeash »

aardvark179 wrote: post #7

"Historically, Bitcoin exchanges that suffered significant losses turned into fractional reserve banks, only to fold later." That is not what fractional reserve banking is and I wish bitcoin articles would stop misusing the term.

The continued misuse of that term seems telling. If they really think this is how normal banks work, it helps explain why they set up these bitcoin systems in such crazy ways.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#26

Post by threeseed »

rdtsc wrote: post #8

Please don't be MongoDB, please don't be MongoDB ... Sigh > a failure of distributed systems academics to educate developers and to equip them with clear-thinking frameworks. Here is the thing, distributed systems are not standard academic courses. Just like networking they are often optional. That is really sad and it needs to change. The CAP theorem is not something fringe and exotic anymore it should be standard t…

Have you actually used the database since if you did you would know that the write concern was set to FSYNC_SAFE by every single driver (before it was the default) and given the lack of configurability should have been known by every developer.

It never ceases to amaze me how few technical people actually "get it" even for products designed for themselves. Many, many people like things to be simple and easy. MongoDB fits this criteria perfectly and no matter how many times you call it a shitty product isn't going to dampen its popularity.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#28

Post by mriou »

patio11 wrote: post #6

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, sophisticate…

Banks 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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#30

Post by ams6110 »

edwintorok wrote: post #19
ChuckMcM wrote: post #10

Its unfortunate to use the ATM example because just such an exploit was used by carders [1] to get more money out of accounts than the accounts actually had. [1] http://time.com/48344/hackers-target-atms-for-unlimited-with...

ATMs aren't as smart as the article says either: "the real code will check to see if there are sufficient funds". I noticed that (some?) ATMs around here tend to implement this flawed algorithm, paraphrasing the article: 0. database.begin() 1. mybalance = database.read("account-number") 2. newbalance = mybalance - amount 3. database.write("account-number", newbalance) 4. database.commit() 5. dispense_cash(amount) At…

Wow I've never seen this happen. What happened to step -1:

  if (cash_in_machine
Post reply on HN