6 ms·

I hope he gets them off MongoDB. I still can't believe they let me double sell without even contacting me afterwards (I sold ~10 bitcoins when it was around $80

by consz 13y ago

I hope he gets them off MongoDB. I still can't believe they let me double sell without even contacting me afterwards (I sold ~10 bitcoins when it was around $800 and the site was exceptionally busy -- had USD in my Coinbase account afterwards and the bitcoins never left, and I was able to transfer both the USD and BTC out afterwards).

noname123 13y ago
Can you tell me if you know the technical limitation of MongoDB that allows a double-sell? Is it because it doesn't have transaction integrity?
- SomeoneWeird 13y ago
  Mongo shouldn't be used for financial applications, it doesn't have ACID support.
  - mbesto 13y ago
    Why, today, people refuse to use trusted SQL RDBMS's still boggles my mind...
    - gnu8 13y ago
      SQL isn't buzzword compliant. It's ironic really. MongoDB is the new Oracle, while Oracle would actually be a reasonable solution here.
  - tzs 13y ago
    I think the problem is more with the architects of the applications than with Mongo. You can safely use a non-ACID database for financial applications. You just have to take care of the parts of ACID you need yourself. It's tricky to get that right, though, so most developers would be much better off picking a database that does it for them.
  - jasondc 13y ago
    I've worked on a few large scale financial databases and none of the ones I've worked on use transactions (using Oracle). Most of them are insert only with bi-temporal data: http://en.wikipedia.org/wiki/Bitemporal_Modeling http://en.wikipedia.org/wiki/Bitemporal_Modeling
    - lclarkmichalek 13y ago
      Do you have any more info on that technique? The wikipedia article is a little scarce.
      - buro9 13y ago
        A simple entry into the field is to imagine that instead of storing a row in which you have a single balance, you would instead have an append-only table in which you store all transactions including their timestamp and auditing info. The balance would then be calculated as the sum of transactions, and you could modify the query to view a balance in the past by only including transactions before a certain point in time. A reversal or correction would be an append action, not a modification to existing data. Thus giving you an accurate history of the data. This is a simple entry point, as bitemporal modelling usually affects the entire datastore and also has to handle potentially massive data and so requires ideas of how to archive old data, and provide performant ways of knowing the current state. There are lots of tricks here, and the sum of those tricks is how bitemporal modelling is achieved.
        jes5199 13y ago
        I've seen the before-and-after at a company that didn't use this sort of modelling and then added it. It was like night and day - suddenly we stopped making embarrassing errors with people's money. Even without really optimizing it for speed, and just using MySQL, and without changing any of the other data model, it works.
        jasondc 13y ago
        Interesting, could you describe how the errors occurred?
bowmessage 13y ago
This happened to me and many others on Reddit. It's something that they manually audited it seemed and I got emails about it letting me know that they would be correcting the issue about a week after it happened. Sounds like in your case they never contacted you though? Wow. Still, it made me wonder if I could have just ran with the money and drained the bank acct they had access to... Not a good thing for an exchange to be doing.
- jedanbik 13y ago
  Manual audits? What is this, the Cretaceous period?
smtddr 13y ago
>>had USD in my Coinbase account afterwards Unlike btc-e.com, I don't think you can have a USD balance on coinbase. If you sell your BTC, you _must_ select the bank to have your money wired too.
mcv 13y ago
Is this Coinbase? Sounds like they're not a lot better than all the others then: amateurs unaware of best practices for what they're dealing with. MongoDB and similar NoSQL DBs are really cool when you need to deal with vast amounts of statistical data or stuff like that, but for financial transactions, you really need ACID transactions. There's just no substitute for that.

by consz 13y ago

noname123 13y ago

Can you tell me if you know the technical limitation of MongoDB that allows a double-sell? Is it because it doesn't have transaction integrity?

SomeoneWeird 13y ago
Mongo shouldn't be used for financial applications, it doesn't have ACID support.
- mbesto 13y ago
  Why, today, people refuse to use trusted SQL RDBMS's still boggles my mind...
  - gnu8 13y ago
    SQL isn't buzzword compliant. It's ironic really. MongoDB is the new Oracle, while Oracle would actually be a reasonable solution here.
- tzs 13y ago
  I think the problem is more with the architects of the applications than with Mongo. You can safely use a non-ACID database for financial applications. You just have to take care of the parts of ACID you need yourself. It's tricky to get that right, though, so most developers would be much better off picking a database that does it for them.
- jasondc 13y ago
  I've worked on a few large scale financial databases and none of the ones I've worked on use transactions (using Oracle). Most of them are insert only with bi-temporal data: http://en.wikipedia.org/wiki/Bitemporal_Modeling http://en.wikipedia.org/wiki/Bitemporal_Modeling
  - lclarkmichalek 13y ago
    Do you have any more info on that technique? The wikipedia article is a little scarce.
    - buro9 13y ago
      A simple entry into the field is to imagine that instead of storing a row in which you have a single balance, you would instead have an append-only table in which you store all transactions including their timestamp and auditing info. The balance would then be calculated as the sum of transactions, and you could modify the query to view a balance in the past by only including transactions before a certain point in time. A reversal or correction would be an append action, not a modification to existing data. Thus giving you an accurate history of the data. This is a simple entry point, as bitemporal modelling usually affects the entire datastore and also has to handle potentially massive data and so requires ideas of how to archive old data, and provide performant ways of knowing the current state. There are lots of tricks here, and the sum of those tricks is how bitemporal modelling is achieved.
      - jes5199 13y ago
        I've seen the before-and-after at a company that didn't use this sort of modelling and then added it. It was like night and day - suddenly we stopped making embarrassing errors with people's money. Even without really optimizing it for speed, and just using MySQL, and without changing any of the other data model, it works.
        jasondc 13y ago
        Interesting, could you describe how the errors occurred?

bowmessage 13y ago

This happened to me and many others on Reddit. It's something that they manually audited it seemed and I got emails about it letting me know that they would be correcting the issue about a week after it happened. Sounds like in your case they never contacted you though? Wow. Still, it made me wonder if I could have just ran with the money and drained the bank acct they had access to... Not a good thing for an exchange to be doing.

jedanbik 13y ago
Manual audits? What is this, the Cretaceous period?

smtddr 13y ago

>>had USD in my Coinbase account afterwards Unlike btc-e.com, I don't think you can have a USD balance on coinbase. If you sell your BTC, you _must_ select the bank to have your money wired too.

mcv 13y ago

Is this Coinbase? Sounds like they're not a lot better than all the others then: amateurs unaware of best practices for what they're dealing with. MongoDB and similar NoSQL DBs are really cool when you need to deal with vast amounts of statistical data or stuff like that, but for financial transactions, you really need ACID transactions. There's just no substitute for that.