A Just-So Story About What May Have Happened At Mt.Gox

A just-so story is a story that has been retrospectively crafted to fit the facts, often by the skin of its teeth. I heard an interesting just-so story at the Financial Cryptography '14 conference about Mt. Gox that incorporates all of the claims made by Mt. Gox as if they were true, and weaves a technically-sound yarn that can explain what happened. And it has two separate endings.

So, here are the claims made by Mt. Gox on how they lost close to a half billion dollars:

transaction malleability was involved in their collapse,

they faced malicious hackers,

their funds were "technically speaking not lost, but temporarily unavailable."

And just two days ago, they announced that they discovered close to 200,000 Bitcoins in a wallet from 2011. They thought the wallet contained useless keys, but it turned out to have keys that were worth $100M. Let's leave aside the fact that these guys mistakenly stumble onto 9-digit paydays with the same frequency the rest of us find quarters in between sofa cushions, and see if we can fit a sensible story to these data points.

It's challenging to incorporate all these claims into a coherent narrative, because they plaintively do not make sense together, at least, not if we interpret them in the usual manner. Until now, that interpretation made two assumptions. First, everyone assumed that transaction malleability was used by an attacker to get Mt.Gox to issue multiple payouts, draining their reserves. It's indeed quite difficult to drain 850,000 BTC this way, as the double-spend requires massive social engineering. When I raised this issue earlier, some people claimed that the attacker's job was easy because Mt. Gox performed auto-reissues. But in the meantime, hackers broke into Mt. Gox and leaked their code for manipulating wallets. I looked through this code and did not see any hints of auto-re-issue. Now, it might be elsewhere, perhaps in a wrapper class, but it wasn't in what has been leaked so far. So it still looks like double-expenditures would be difficult to trigger. Second, everyone assumed that, when Karpeles blamed hackers, he indicated that a hacker broke in and stole Mt. Gox's cash. And a hacker, no matter how good, cannot jump over an air gap and gain access to coins in cold storage. It's not physically possible.

But what if transaction malleability and hackers were involved, not to steal money out of Mt. Gox, but to leave it in Mt. Gox's coffers, while simultaneously confusing Mt. Gox's accounting to the point of bankruptcy?

A Malleable Story Here's how this story goes: Mt. Gox must have been set up to transfer excess Bitcoins from their hot wallet into their cold storage periodically. This is a sensible setup to make sure that the amount of money at risk in the hot wallet does not exceed a certain amount or percentage. Now suppose that the transactions that transferred money from the hot to the cold wallet were highly malleable. For instance, they could have been legal transactions that fit the Bitcoin specification, but not transactions that the standard client would ever produce. For example, Mt.Gox may have been issuing transactions that encode the length field in two bytes, when the standard implementation would have used the short form which encodes the length in a single byte. It could well be the case that someone downstream of Mt. Gox on the peer-to-peer network, like a miner that is creating blocks or someone just relaying transactions, decided to helpfully reencode these transactions. If they were to rewrite the transaction to, say, encode the length in a single byte instead of two bytes, that would still retain the validity of the transaction, but change the transaction hash. Someone could do this as part of their normal parse-examine-reconstruct-forward loop, without any malice involved. Or it could be hackers who were just doing their usual mischief, for the lulz or whatever else. So the malleability of Bitcoin transactions is not being used by a malicious hacker to get Mt.Gox to double-spend. Instead, the transactions go through, as intended by Mt. Gox, and transfer the funds from the hot wallet (under Mt. Gox's control) to the cold wallet (also under Mt. Gox's control). But in the process, the transaction ID gets changed on occasion, depending on whether Mt. Gox's original transaction or the "malleated" transaction made it to the miners first. Once the transaction ID changes, Mt. Gox would lose the ability to further spend the money at those addresses, because they need to specify the transaction IDs in order to reclaim the money in them. And Mt Gox may not be aware of this problem for a long long time. Presumably, when Bitcoin was going to the moon and the Mt. Gox user base was growing, the flows were mostly one-way into the cold wallet. So they may not realize that the transaction IDs they have recorded correspond to bogus transactions that were modified inside the network and thus have a different ID. When their outflows increase, and they try to transfer coins from the cold wallet to the hot wallet, they'd suddenly find out that some percent of the transactions to their cold wallet do not appear anywhere in the blockchain. They might even think that these transactions never took place. Now, being unable to draw on money in cold storage should have raised alarm bells at any proper organization handling money, but every programmer has seen junior programmers do that special "let's run it again and see if it works" thing that gives our profession a bad name. And trying to get funds out of the cold wallet a second time would actually work some of the time, depending on their luck and the percent of "malleated" transactions that had made their way into the cold wallet. Any normal company would task a team with looking into why some transactions that they thought had made it to the cold wallet were unspendable. But such a team of astrocoders-to-the-moon may very well be lulled into a false sense of security. They may erroneously decide that their transaction was not accepted by the miners (even though it went through, but under a different ID). They would then conclude that there was no harm done, because an unsuccessful inter-Mt.Gox-wallet transaction would have left behind cash in the hot wallet. After all, if a hot-to-cold transfer failed to take place, the next day's periodic task would take care of it. So, what could really go wrong when transferring money between internal accounts? A lot, it turns out, depending on what happened next under this theory.

Malleating with a Happy Ending So, if this theory is true, and you're wearing rose-colored glasses, Mt.Gox's transfers actually took place, but Mt.Gox lost track of the transaction IDs, and therefore is not in a position to easily name and exercise the funds. But they still retain the all-too-critical private keys required to use the funds. Under this ending to this just-so story, all that one has to do is to scan for malleated transactions from the Mt.Gox hot wallet. The money is still in existence and under Mt.Gox control, nothing was stolen, it's all one big accounting error, and everyone can be made whole again by simply scanning through the blockchain and identifying the modified transaction IDs. This explains the "coins are not available at this time" story, as someone needs to go through the blockchain, and discover the new transaction ID for each malleated transaction, which could take time. But with 850K BTC at stake, Mt. Gox should have been able to bring in experts who could have sorted out their books. The fact that they chose to declare bankruptcy instead indicates that, perhaps, this is not the ending we're living through.

Malleating with an Unhappy Ending An alternative ending to this theory is that Mt.Gox went through their keys and deleted the private keys corresponding to addresses for transactions that they thought never took place. This is a disaster scenario, as the money then suddenly and irretrievably disappears. If this is the case, this software error would rank up there in the top-10 most costly software errors of all time. Perhaps not as bad as the Ariadne-5 rocket control system that cost billions when the spaceship turned into a giant one-off fireworks project with very neat little European flags drawn on the side, but certainly right up there. While no sane person would clean up their wallets like this, we're already off of the short and narrow path of sanity right now, trying to make sense of an insane outcome.

Lost and Found Coins Since Mt. Gox recently recovered about 23% of the deposits that they initially said they lost, perhaps the story has both endings: they zapped their keys as in the unhappy ending, but were able to locate and recover some of them from a backup. This also fits the claim that they thought this old wallet was empty -- they would think that the keys were worthless if they thought the corresponding transactions did not take place.

Actual Story? Just-so stories succeed only to the extent that people want to believe in the outcome, and are willing to accept any and all twists of the backstory. [This is partly why the so-called pseudoscience known as evolutionary psychology was able to spew so much hateful drivel. Ironically, the ringleader of the ill-fated evopsych movement was another Satoshi, Satoshi Kanazawa, a master troll who made a complete fool out of himself and his employer, and in a first-of-its-kind action, was officially banished from the Internets for a year.] In this case, this story takes the claims made by Mt. Gox at face value, couples them with a hefty dose of "let's assume they were not at all malicious but stupendously incompetent," and fits a contorted explanation. And it's possible to invent even more complicated backstories by mixing and matching. Wanna believe that Mt. Gox lost the transaction IDs to transaction malleability, and the keys to a hacker who broke in? Or they lost parts of the keys to the broken "RAID-like" backups they were performing and need to brute-force the rest? Go right ahead. But the simplest explanation of all, the one that serves as my default in the absence of a clear technical explanation from the Mt. Gox techies, is that Mt. Gox's collapse involved simple fraud and/or theft, with insider assistance. The latest discovery of 200K BTC could be a simple case of cooling the mark out. After every bankruptcy, some creditors will emerge with sharper teeth than the rest of the meek people lining up for their shares. A savvy fraudster will want to disperse some cash to get these aggressive people, the ones with mob ties, off of his back, especially considering the type of money laundering uses that Bitcoin attracted in its early days. The same way AT&T offers you a good plan if you're the kind of person who calls and complains every six months, and rips you off if you're old, frail or too busy, a fraudster will want to differentially compensate the aggressive versus complacent marks. Almost every other exchange collapse has had a "partial comeback/recovery" phase for exactly this reason, and Mt. Gox could just be doing the same thing. Here's a simple rule to decide how to pick between different explanations: if you are inclined to believe that people are inherently good but likely stupid, then the just-so story above is for you. If you suspect that some people can be smart and evil, then the theft/fraud explanation fits the bill. You pick. Like a good summer drama, Act 1, in which a PHP programmer balancing on a blue exercise ball came to control half a billion dollars for a ride to the moon, was captivating. Act 2 will introduce many additional twists to the story. This fantastic just-so story is another addition, one that is likely to be proven wrong by a truth that will turn out to be far stranger than any fiction. For after all, just-so stories need to be believable, while reality just is. Overall, I can't wait for Act 3 where it all gets resolved. Just hope that the main man isn't killed off too early.

Credits I heard this story from an attendee at Financial Cryptography conference in Barbados who has chosen to remain anonymous.

Share on Twitter Share on Twitter

Share on Facebook Share on Facebook

Share on Linkedin Share on Linkedin

Share on Reddit Share on Reddit

Share on E-Mail Share on E-Mail

Please enable JavaScript to view the comments powered by Disqus.

Disqus