[smtddr]

>> hindsight

I'm only making this comment because you used the term "hindsight".

Let me first start off by saying I feel very, very sorry for all the people who lost funds in MtGox. It'll take awhile before you get over the pain of losing a life-changing amount of money. But let's be very clear about this; hindsight wasn't needed here. The warning signs that MtGox was a house of cards became visible a long time ago. Definitely before the disabling of BTC-transfers. A lesson should have been learned here and nothing like this should happen to you again.

-- http://www.livetradingnews.com/the-bitcoin-tangle-were-warni...

"Some signs of a strain were visible early on. The exchange was quick to accept purchases but slow in giving them back. Additional proofs were asked for. The site also had technical issues; some users complained that passwords were displayed in plain text. Users are now left wondering if the small hints portrayed deeper crises."

[mtgoxloser]

I will say that the article you linked is almost garbage. It glances over the "clues" very quickly which I will assume due to lack of knowledge.

The complaint that passwords were displayed in plain text is not anywhere near recent. Even in 2011 when I started using MtGox, passwords were hashed. Granted, early on the passwords were only hashed with 1 pass of SHA256, but later on passwords were stored to much better standards.

How do I know this? Because they got hacked twice in 2011, both through SQL vulns. Once a database dump being leaked, and another time a user's account balance was changed and the attacker cleared the bid side of the market book. Trades were rolled back, and MtGox took the loss; nothing remote of this severity ever happened again.

Another thing I do remember [is this](http://imgur.com/xMeW43a), and it seems much more aligned to what the article is talking about. But seriously, look at the URL. The only issue is when someone looks at that user's browsing history, but even this wasn't an issue in 2011.

--

Banking problems were not apparent until last year. It was well understood that banks and Bitcoin exchanges had harsh relationships. Bitfloor, the most popular US-based exchange was shut down due to banking problems; they were unable to find any banking partner that were willing to accept them. MtGox having delays in fiat withdrawals were understandable since it was by far the biggest exchange.

--

Most people who call us idiots for not connecting the dots earlier are those who haven't been here long enough. For many of us, MtGox went down over the years but all to recover. Both Luke-Jr and gmaxwell (core dev) had a significant sum of coins stored on MtGox too. It shows the trust we had in MtGox over the years.

--

One last thing though, is that I will attribute Bitstamp's late popularity causing them to dodge a bullet. The reason MtGox had written their own bitcoin implementation was because the bitcoin reference client was unable to handle their volume of Bitcoin transactions at the time.

Transaction malleability was documented, but not well known issue for Bitcoin. Even the reference Bitcoin client was affected.

So the fatal flaw that MtGox's implementation made when resending transactions (because a different transaction id was accepted and their system did not see it) was it did not reuse the same inputs when resending the transaction.

In the reference bitcoin client (bitcoind), it makes sure to use at least one of the same coin inputs, so if the original transaction (but different tx id) did get accepted into the network, the client would attempt to resend using the same input, but it would get rejected by the network because it was a double spend.

[Xdes]

>Most people who call us idiots for not connecting the dots earlier are those who haven't been here long enough.

I've been a spectator for quite a few years and after their first hack I was out of MtGox. It was tempting to go back, but time-and-time again they proved their incompetence to a degree that I was not going to risk my holdings. They are amateurs and I have my doubts as to whether they've properly applied any knowledge they've gained over the years.

[berkes]

I've been advocating Bitcoin and trading with it since early 2011. Yes, MtGox was unstable. But so were other platforms.

I've tested withdrawal on MtGox every three years, to see and experience their current liquidity: Getting out Euro's was easy: getting out BTC has never been a problem. Probably them being my three-monthly-test, only a few hundred Euro or a fraction of a Coin at most, made it go through just fine.

Yes, there were apparent problems, and yes, these were highlighted everywhere. But in that case: with very little searching you'll read about people having problems bitstamp, kraken, btc-e, and whatnot.

This is a confusing market; one that requires you to keep a keen eye on the social-workings of some niche-forum, a reddit-community and a blogosphere around all that. In that sense, it might not be hindsight, no. But in that sense, /any/ problem was predicted. By someone. On some Forum. Or Blog. Or reddit-self.post.

[smtddr]

I can't really say anything you're saying here is false, but I still hope the lesson has been learned by most people affected. This wasn't 100% unavoidable bad luck and this kind of thing shouldn't happen to MtGox's victims twice.

But perhaps I'm taking for granted my tech-knowledge(or bias opinion). Let me say some things that jumped out at me immediately as mistakes that should have never happened to begin with when making an application dealing with people's money.

---The password in URL thing.

The issue with that password in browser's history is that it becomes an easy target for malware. Just like there's malware that knows the default location of wallet.dat, malware that scrubs your web history will find it. Making it worse is the fact that there are already a lot of malware that hijack browsers and monitor where it's going. At least wallet.dat can have a passphrase. Then you have those tools that are designed to help end-users by keeping their web history synced with other computers and/or devices. In short, web history is constantly exposed to 3rd parties so no personal info should end up there since you don't know how secure the 3rd parties are handling your data. At least, not passwords, SSN, etc. Another thing is servers tend to keep urls in access.log which tend not to get the same level of security consideration as the rest of the webapp. They should have sent it in POST body which isn't stored in access.log(at least not by default).

----The password hashing thing

Security 101; you don't just hash passwords once with no salt. Existence of rainbow-tables make that insecure and even a novice should have known that before starting. Also, according to this article[1] it was a "saltless MD5"[2?] hash.

----SQL vuln

I don't claim to be a DB expert but I do know using stored-procedures, instead of concatenating a bunch of strings together partially from user-input to form an SQL statement, makes SQL injection nearly impossible. I also believe there are some nice SQL sanitation libraries out there. But I can't judge this too hard because I don't know exactly where the SQL injection happened. Sometimes hackers do something really clever and put the malicious SQL in a place that's not normally user-input; like a cookie value for an authtoken.

----Trades roll back

I did not see that solution as a valid way to do things. I still don't fully understand how that didn't screw over all kinds of people. Can etrade.com decide to roll back 1 day of activity?

I dunno; all these things put together just gave me the feeling that one day these guys would be in trouble. The right thing to do after first, or at least 2nd, hack was a full audit of their whole system by someone who knows about these things. They just didn't show any signs of learning from their mistakes. e.g., like the postmortems that other companies sometimes post up detailing the problem and steps to recover. MtGox seemed to just be reactionary and only enough to solve the immediate problem. I'd advise anyone going forward that if you see similar behavior in anything you deal with, not just bitcoin-related, you run away. Also, a red-flag for me is any system where it's easy to put money into but hard to get out without a very sensible reason.

1. http://www.dailytech.com/The+Death+of+Bitcoins+Mt+Gox/articl...

2. This article claims there was a salt... http://www.dailytech.com/Inside+the+MegaHack+of+Bitcoin+the+...

[DCoder]

> I also believe there are some nice SQL sanitation libraries out there. This is not the right approach. Separating the query structure from the data is the right way to go - parametrized queries are much safer than sanitization, which is subject to all sorts of encoding headaches.

[outworlder]

About the SQL injection thing: you do not need to use stored procedures, just parametrized queries. And do not 'sanitize' input text to prevent SQL injections, ever. It will bite you in the future.

[pakitan]

The signs were there, we all knew that. It's just that hindsight makes you believe the signs meant 100% probability Gox will go down. But back then with the limited information everyone had, that was definitely not the case. At some point Gox's bitcoin price had a 20% premium over the rest of the exchanges. So, if he wanted to get out of Gox immediately, he'd have to buy BTC, withdraw and sell at another exchange. Which means 20% loss or $100K. At that point he'd have ask himself if the probability of Gox being completely insolvent is really that great to be worth taking such a hit. And I don't think it was - the loss of 700K BTC came as a surprise even to the biggest Gox critics.

[MartinCron]

You also don't need hindsight to know that investing/trading/speculating in a brand new type of asset in a space with nearly zero regulatory controls is not for the faint of heart.

Just like the handful of people who realized that the Bernie Madoff claims were too good to possibly be true, they didn't need hindsight. There's a great This American Life story about one such person: http://www.thisamericanlife.org/radio-archives/episode/376/w...