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

31–40 of 69 posts

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#31

Post by threeseed »

nemothekid wrote: post #4

While I do recognize this is a marketing piece for HyperDex, I'm disappointed HyperDex only chooses to compare itself with MongoDB and Cassandra. It would be different if HyperDex was fully open source and free, but its not. The "transaction" feature is only available with a license, which in most cases will price you out of any developer who is looking to start a bitcoin exchange. So unfortunately it comes across as…

Cassandra's transaction support has been improving pretty rapidly.

http://www.datastax.com/dev/blog/lightweight-transactions-in...

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#32

Post by threeseed »

ams6110 wrote: post #30
edwintorok wrote: post #19

Earlier quoted context omitted.

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

He is talking about a failure to dispense the cash.

I've had this happen twice to me whilst overseas.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#33

Post by bkirwi »

A bit irritated at how the author complains about other databases astroturfing on Hacker News, then writes a glowing post about HyperDex without mentioning that he's one of the authors.

That said, I agree with the thesis that current-generation distributed systems provide a terrible API for users who actually want to get concurrency right. I'm optimistic about projects like Summingbird[0] and Bloom[1], which run very high-level declarative programs with simple consistency guarantees.

[0] https://github.com/twitter/summingbird [1] http://www.bloom-lang.net/

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#34

Post by atmosx »

> It points to a social failure: a failure of distributed systems academics to educate developers and to equip them with clear-thinking frameworks.

So, will the OP do an exchange and show us how it's done using his database of and approach of choice. Because writing articles on other's failures is kinda of... Easy.

I'm a little sick of this attitude. Nothing personal with - what I thought was Sinan Eren at first, confusing the names after so many years - the OP here, but given the fact that he is deliberately calling out amateurs and poor designers people who (apparently) deserved it, he might very well create a secure bitcoin exchange in the real world, using his technologies.. There is a huge market for that, today more than ever.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#35

Post by Alex3917 »

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.

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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#36

Post by sillysaurus3 »

atmosx wrote: post #34

> It points to a social failure: a failure of distributed systems academics to educate developers and to equip them with clear-thinking frameworks. So, will the OP do an exchange and show us how it's done using his database of and approach of choice. Because writing articles on other's failures is kinda of... Easy. I'm a little sick of this attitude. Nothing personal with - what I thought was Sinan Eren at first, con…

The attitude is warranted when they're losing other people's money.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#37

Post by atmosx »

sillysaurus3 wrote: post #36
atmosx wrote: post #34

> It points to a social failure: a failure of distributed systems academics to educate developers and to equip them with clear-thinking frameworks. So, will the OP do an exchange and show us how it's done using his database of and approach of choice. Because writing articles on other's failures is kinda of... Easy. I'm a little sick of this attitude. Nothing personal with - what I thought was Sinan Eren at first, con…

The attitude is warranted when they're losing other people's money.

Totally get that, but his approach seems a little snooty to me and runs throughout the article that's why I had this reaction/comment.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#38

Post by JohnTHaller »

nemothekid wrote: post #4

While I do recognize this is a marketing piece for HyperDex, I'm disappointed HyperDex only chooses to compare itself with MongoDB and Cassandra. It would be different if HyperDex was fully open source and free, but its not. The "transaction" feature is only available with a license, which in most cases will price you out of any developer who is looking to start a bitcoin exchange. So unfortunately it comes across as…

> It would be different if HyperDex was fully open source and free, but its not. The "transaction" feature is only available with a license, which in most cases will price you out of any developer who is looking to start a bitcoin exchange. So unfortunately it comes across as "If only you had spent $x/mo, buying our product, then you wouldn't have had this problem!"

Just use PostreSQL. Open source. Free. ACID compliant.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#39

Post by jasomill »

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…

Interesting. In one particularly ADHD-inspired case, I've also seen

  5. Dispense cash
  6. Wait a minute or so
  7. Retract cash
where 7 did not lead to a credit on my account until several days after I reported the problem to my bank. That's probably by design, however, since otherwise the machine would require automated defenses against surreptitious replacement of dispensed bills with counterfeits.

Your example could be a similar failsafe against cases where the machine fails to properly dispense cash in a manner that nevertheless allows the cash to be retrieved. Otherwise you have to carefully separate errors that can't possibly lead to cash being dispensed (e.g., hopper empty) vs. those that might (e.g., bills jammed somewhere in the dispenser mechanism).

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#40

Post by zorlem »

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…

I, too, don't like the way MongoDB works and is marketed, but I would not bet too strongly on them failing. Only 10 years or so ago MySQL did pretty much the same, but they managed to succeed, despite there being better alternatives at the time.

Even today, after all the development effort put into MySQL and its derivatives, there are still better and more capable databases, but that doesn't prevent MySQL from being one of the top three RDBMS-es (and we can bet it is the most popular FOSS RDBMS).

Post reply on HN