Live data from Hacker News

Bitcoinica MtGox account compromised

bitcointalk.org

91–100 of 108 posts

Re: Bitcoinica MtGox account compromised

#91
post #82
post #79

Earlier quoted context omitted.

AFAIK Bitcoinica was the only site offering BTC derivatives, so presumably some people figured the potential profit was worth the risk. More generally, all Bitcoin exchanges seem to be run by amateurs, so people have to deal with them to cash out.

I wonder why. There seems to be a huge gap in the market for a professionally run enterprise here. Or at least, anything more focused beyond students half-assing it part-time.

Bitcoin market activity may not be large enough to ever pay back the significant cost of building a secure exchange. Also, as TradeHill and CampBX discovered, people just won't move off of MtGox no matter how bad it is.

Re: Bitcoinica MtGox account compromised

#92
post #48

Earlier quoted context omitted.

I'm not sure why anyone would believe him enough to send him money. Perhaps they don't understand how absurd that claimed interest rate is? :x

If the money were funding a payday loan shop, that's the kind of interest rate they charge to their customers. ie, take in money via Bitcoin, loan out dollars to poor people as payday loans at very high rapidly compounding interest rate, pay somewhat smaller interest rate to Bitcoin funders.

I don't think payday loan shops are ever constrained by the amount of capital they can loan out, though. If they were, it would be trivial for them to borrow money at normal rates (say 10%) from a traditional bank and solve that problem. I'm sure they are much more constrained by the physical locations/marketing/accessibility of customers/etc and no money at 3000+%/year is going to help them solve those constraints.

Re: Bitcoinica MtGox account compromised

#93

Reusing passwords. Check. Using passwords after they've been known to be compromised. Check. Storing passwords protecting north of a million dollars in an online password storage system and not even using the provided two-factor auth. Priceless. This is just like the Mtgox guys claiming the bcrypt was not good after getting caught using unsalted MD5. This is amateur bullshit and the lack of actual penalties makes me…

Surely you mean integer, not "decimal", right? I'm not an expert, but to my understanding none of the values in the bitcoin protocol are expressed as base-10 fractions.

It's a nit, obviously, but if you're going to ding someone for naive mistakes...

Re: Bitcoinica MtGox account compromised

#94
post #93

Reusing passwords. Check. Using passwords after they've been known to be compromised. Check. Storing passwords protecting north of a million dollars in an online password storage system and not even using the provided two-factor auth. Priceless. This is just like the Mtgox guys claiming the bcrypt was not good after getting caught using unsalted MD5. This is amateur bullshit and the lack of actual penalties makes me…

Surely you mean integer, not "decimal", right? I'm not an expert, but to my understanding none of the values in the bitcoin protocol are expressed as base-10 fractions. It's a nit, obviously, but if you're going to ding someone for naive mistakes...

Fixed-point DECIMAL representation in the database is just as good as storing Bitcoin values as integers. Baked into the field definition is the amount of precision. And Python and other languages have features to work with fixed-point numbers. This approach relieves the mental overhead and complexity of converting to integers (which might overflow a 32-bit int) and back all the time.

Re: Bitcoinica MtGox account compromised

#95
I know there is a temptation to blame bitcoin itself here, but wow... this is just some amateurish security on the part of these bitcoin sites. If the big banks were doing this, it would be cataclysmic disaster. Instead, the big banks have found other ways to drive themselves (and your money) into the ditch, and it dwarfs anything that bitcoin sites can manage to lose.

Re: Bitcoinica MtGox account compromised

#96
post #93

Earlier quoted context omitted.

Surely you mean integer, not "decimal", right? I'm not an expert, but to my understanding none of the values in the bitcoin protocol are expressed as base-10 fractions. It's a nit, obviously, but if you're going to ding someone for naive mistakes...

Fixed-point DECIMAL representation in the database is just as good as storing Bitcoin values as integers. Baked into the field definition is the amount of precision. And Python and other languages have features to work with fixed-point numbers. This approach relieves the mental overhead and complexity of converting to integers (which might overflow a 32-bit int) and back all the time.

I just looked this up (feel free to correct me if you think I've missed something): the value field in a TxOut is a 64 bit unsigned integer. It's true that by convention the unit is 1e-07 BTC (i.e. a decimal fraction), but nothing in the protocol actually cares, the "decimalness" is just in what you call it. Implementing this with decimal math is just wrong, and likely to break your implementation due to subtle bugs. Storing it in a database as a decimal fixed point is plausible as it prints nicely, but in no way would I consider that choice "just as good as" a quantity that was designed to fit in a native machine word.

Re: Bitcoinica MtGox account compromised

#97
post #38

> Unbeknownst to us, Tihan was using the mtgox api key as the password for a website called LastPass. Unbelievable. They decide to use a password escrow service... and use a duplicate password to secure it. This is 100% cargo cult security. Clearly whoever did this had no idea what the value of LastPass was, just that it was what all the cool security kids were doing. The choice of the high-value BtGox key was (stagg…

It's even beyond using a duplicate password which as you point out is ignorant. They were so unclear on the concept that they used a password that was written down into their source code, and once that source code was stolen they didn't change that password!

They also failed to utilize the two different free multi-factor options LastPass offers (not to mention the premium ones).

LastPass tries to educate people and push them on not utilizing the same password anywhere with a security challenge, but that clearly didn't teach the concept here.

Their last breach involved losing access to their email: info@bitcoinica.com -- so what email did they use here with LastPass? info@bitcoinica.com They didn't utilize the security email either.

It is all unbelievable.

How do we drag this out of cargo cult security?

I see some are pushing certifications; If I made a free LastPass certification that both proves you understand the concepts, and that you're currently putting them into practice by showing that you/your company has multi-factor enabled would people demanded it?

Re: Bitcoinica MtGox account compromised

#98
post #96

Earlier quoted context omitted.

Fixed-point DECIMAL representation in the database is just as good as storing Bitcoin values as integers. Baked into the field definition is the amount of precision. And Python and other languages have features to work with fixed-point numbers. This approach relieves the mental overhead and complexity of converting to integers (which might overflow a 32-bit int) and back all the time.

I just looked this up (feel free to correct me if you think I've missed something): the value field in a TxOut is a 64 bit unsigned integer. It's true that by convention the unit is 1e-07 BTC (i.e. a decimal fraction), but nothing in the protocol actually cares, the "decimalness" is just in what you call it. Implementing this with decimal math is just wrong, and likely to break your implementation due to subtle bugs.…

Yes, the internal representation of Bitcoins is the 64-bit unsigned INT, but I'm talking about storing customer account balances, trade prices, etc. I would not use DECIMAL if I were writing an alternative client for Bitcoin or for some other software that must create network transactions at a low level.

Even the RPC protocol for the main Bitcoin client returns fixed-point numbers and expects non-integers for input arguments [1].

But I think we can all agree that using FLOAT for this kind of thing is just plain wrong.

[1] https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls...

Re: Bitcoinica MtGox account compromised

#99
post #25

This is starting to prove -- the hard way -- why regulations, certifications, and all that other stuff that feels like meaningless overhead the majority of the time has become a grudgingly accepted part of our lives. It comes back to the most difficult problem: you inevitably need to trust someone, so how do you minimize your risk in that trust? I always thought the Bitcoin trust issues would revolve around the inabi…

Banking, as regards regulation, is a special case. If a taxi company or a pizza company goes belly up, people shake their heads sadly and move to a competitor. The free market is the best arbitrator. If a chain of banks goes belly up and people's life savings are gone, you get rioting in the streets. That's the kind of situation that let Hitler into power. For the sake of preserving civilization, governments act as t…

I disagree strongly.

The reason that bank runs and failures are so destructive is because of the state build cartel, driven by central banking. That was built in order to prevent competition and to let fractional reserve(which is in essence fraud) to run wild.

The only reliable way to ensure stability in banking is to separate it from the state and let the free market do what it does in every industry known to man, weed out stupidity and fraud.

Re: Bitcoinica MtGox account compromised

#100
post #96

Earlier quoted context omitted.

Fixed-point DECIMAL representation in the database is just as good as storing Bitcoin values as integers. Baked into the field definition is the amount of precision. And Python and other languages have features to work with fixed-point numbers. This approach relieves the mental overhead and complexity of converting to integers (which might overflow a 32-bit int) and back all the time.

I just looked this up (feel free to correct me if you think I've missed something): the value field in a TxOut is a 64 bit unsigned integer. It's true that by convention the unit is 1e-07 BTC (i.e. a decimal fraction), but nothing in the protocol actually cares, the "decimalness" is just in what you call it. Implementing this with decimal math is just wrong, and likely to break your implementation due to subtle bugs.…

(Ironically this is exactly what I was doing as the language I was using didn't/doesn't [actually rather annoyingly] support decimal types natively so I have various currency types which have different levels of precision and I store BTC as "natively" as possible). That and my code never progressed terribly far and it would have had many more (qualified) eyes looking at it from a number of angles (security, financial data, integrity, replication, etc) before it would've touched the Internet.
Post reply on HN