[M4v3R]

I think that his points against transaction malleability are invalid:

- technical one - Bitcoin clients have a 100 ms delay before they relay messages. An attacker can compile a modified client that doesn't have these limitations and successfully outrun the rest. It was shown once that an attacker managed to successfully modify most of Bitcoin transactions on the network for some time in February

- social one - IIRC Gox had an automatic system, which reissued Bitcoin transfers if they failed. So you didn't need to phone them or convince in any way - Mt.Gox would send you a new transfer (and exhausting inputs has nothing to do here since they had no reason to use raw transactions API which lets you to use specific inputs, and instead they probably just used the more common sendto API) after it detected the old one failed (TXID not found on the network).

[emin-gun-sirer]

Author here. I think there is some subtlety around the technical point that may be getting lost.

Ittay Eyal and I were the ones who discovered an attack against Bitcoin called selfish mining, where we showed how a miner could earn more than his fair share. This attack did not require, but could benefit from, the attacker racing against honest participants on the peer-to-peer network. Some members of the Bitcoin community claimed that the attacker would reliably lose these races because they start behind.

In the article, I point out that there is indeed a transaction race in this case, that people have demonstrated an ability to outrun transactions, and that this has ramifications for selfish mining. I do not claim that there is a technical impossibility -- quite the contrary! The tricks used to make that succeed are identical to what an aggressive selfish miner would use.

To be fair, malleability attacks require a modified client and some network positioning, so there is nevertheless a technical obstacle. Not one that is impossible to surmount, but one that requires some effort.

I did not know that Mt. Gox performed automatic reissues -- thank you for bringing that up. Would you happen to have a pointer that establishes this?

On the whole, I do not believe that malleability accounts for Gox's collapse at all. Even automatic reissues would put at most the hot wallet at risk. Studies of malleable transactions do not show anywhere near the volume required to account for Gox's collapse. And something I did not mention in the post is that the timing of the observed malleable transactions doesn't match the story from Mt. Gox at all. There is undoubtedly more to this story.

[lvs]

Another point is that evidence of significant tx-mal can't be found on the block chain prior to Feb 9 [1]. Now, it's possible that the search wasn't thorough enough, but I find that unlikely. Any reissued transactions must have occurred within a very short period -- a couple of weeks in February -- that could have been attributed to malleability.

[1] http://www.righto.com/2014/02/the-bitcoin-malleability-attac...

[gojomo]

That's only looking at one kind of malleability. Notably, I've been told that MtGox for years issued its own transactions in a non-standard format... so one potential 'attack' would be to mutate those to canonical form and race them into the blockchain. There'd be no evidence of such an attack in the blockchain: only someone who'd been long-archiving losing, non-canonical transactions from multiple places in the network would have a way to estimate the frequency/magnitude of such activity.

[lvs]

That sounds a bit speculative. If someone has a link that shows one of these "non-canonical transactions," that might lend some credence to the idea. Furthermore, if Gox was always issuing weird transaction formats, then looking for addresses that show a statistic prevalence of these would be trivial. Showing that the attack took place would simply require showing addresses that occasionally issued a proper tx, but statistically favored outgoing transactions of the type you describe. That is, there will be evidence in the blockchain if the type of transaction you describe is very specific to gox.

[gojomo]

Their history of oddly-composed transactions could help identify more of their likely addresses, if noone else did the same thing, but that would still be of limited use in funds-tracing depending on whether such addresses were ever reused.

That they've long been issuing valid but unusual signatures was mentioned among other places at: http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_cha...

I'm not sure if this was just a tiny sliver of their transactions, or a large proportion... but it complicates easy analysis of what the malleability losses could be.

[bashcoder]

Good article - it's helpful, and for me it adds clarity to the discussion.

Parsing recent industry statements, it's notable how Coinbase and peers have been using a rather loaded term of art, "bad actor", in reference to Mt. Gox, both directly and indirectly.

Yet even after all that has happened, many are still basing their conclusions on Mt. Gox's past public statements.

[gojomo]

It'd be most accurate to say you rigorously described a kind of mining-cartel attack that had been discussed years earlier, but I know I won't convince you of that, because you only count published academic papers, and the earlier discussions of the same attack all happened in less-formal bitcoin forums.

Regarding MtGox scenarios:

Reliable evidence on what MtGox truly did is scarce, but people have widely speculated that at times they auto-reissued payouts, and without the protective measure of reusing the same inputs. It would be in character – see other examples of their recklessness below.

So while I share your doubt that malleability could have resulted in significant losses, there is a theory for that, which doesn't require extensive social engineering/human-in-the-loop processes. And, if it had been happening for years, only outsiders with a giant archive of long-ago race-losing transactions (that never reached blocks) would be able to estimate the magnitude of the losses. (I don't know any public source for such an archive.)

Similarly, at times Karpeles mentioned that the cold storage was a "paper-based RAID" in 3 parts, or some other scheme in 6 places. As the 'key man' in an enterprise that suddenly found itself atop $100MM+ in easily-transferable assets, his feared threats may have included kidnapping/extortion to force disclosure of the keys. Thus his cold storage scheme may have involved putting necessary key-shares totally outside his easy control, even via people and safety-deposit boxes in other countries. Any "key-loss" scenario should consider the chance law-enforcement-actions or other calamities, far from the MtGox offices or Japanese accounts, have made essential parts of the cold-storage keys unrecoverable, for now and perhaps permanently.

There's a forum thread from years ago where people mention 2600+ bitcoins MtGox lost from their own bad-transaction-issuing code (https://bitcointalk.org/index.php?topic=50206.0;all). Karpeles wrote his own SSH server in PHP. Over the years MtGox suffered SQL injection & cross-site scripting attacks. In the June 2011 'flash crash', the entire user database with weakly-hashed passwords was lost (supposedly via an auditor compromise), allowing outsiders to carry off some unknown number of artificially-cheap bitcoin – but MtGox made customers 'whole' via a database rollback. MtGox later that year made the customers of competing exchange Bitomat whole, at a cost of 17,000 BTC or more, after that exchange lost its keys.

So when speaking of MtGox, we're already in Alice-in-Wonderland territory, with both custom (and often unwisely eccentric) implementation choices, and overconfident grand gestures. It's hard to rule anything out, based on ideas from elsewhere about plausible engineering or business practices.

[lloeki]

> Karpeles wrote his own SSH server in PHP.

I never heard of that one, although I know Mark Karpeles is the author of a few tools in PHP. I met him around 2003 when he developed, hosted and managed a Ragnarok Online (not so) private server (fRO) on Linux (hence his surname, MagicalTux). The whole time he paid the hosting himself. Contrary to more known servers such as eAthena, this server had a unique feature is that it was written in PHP and developed mostly by himself. The server was stable, allowed for quick iteration and took the load quite fine. The whole time he paid the hosting himself. He also wrote an inetd daemon in PHP. Another PHP game project that never took of was 'Inochi', but I can't remember what it was about. He started a few other projects such as a homegrown OS and a VoIP system/company.

Still I can't tell much about the quality of his code since I never read it, and all traces of his code have vanished, and that's been more than 10 years ago. What I can remember though is that he was smart and friendly, but very sloppy at communicating.

For a side story, fRO grew sufficiently big that it caught attention of Gravity and Mark received a cease and desist letter, which he obeyed short of facing a trial. He rebuilt the server soon after though, authorising only a select few members (of which I was one) resulting in something more like a permanent, albeit remote, LAN party, and finally abandoned the project, stepping down and transitioning the management to the player community. The community stayed strong enough even without access to the server that Gravity offered an exit in a form of an officially sanctioned, monthly-paid server. That server was eventually integrated into the official Gravity managed euRO.

[tlrobinson]

"only outsiders with a giant archive of long-ago race-losing transactions (that never reached blocks) would be able to estimate the magnitude of the losses. (I don't know any public source for such an archive.)"

Is that actually the case, or can most/all forms of malleability be detected by looking abnormal transactions that wouldn't have been generated by any known client?

Looking at the known sources of malleability, most of them would never be done intentionally: https://gist.github.com/sipa/8907691

Has anyone done a comprehensive analysis like this yet?

[gojomo]

I don't know of a comprehensive survey of all kinds of malleability evidenced in the blockchain. It should be possible.

The issue with using it to estimate an upper bound on potential MtGox losses is that since some portion of MtGox's historic transactions were non-canonical, a third-party mutation could result in a 'normal' transaction entering the blockchain... but MtGox still confused, perhaps to the point of loss. Any survey would miss such transactions.

Maybe there's a private archive of never-confirmed transactions. Since it seems MtGox at times provided a public feed of (some of?) its own intended transactions, someone who'd been scraping/saving that for long enough might have a useful estimator dataset.

[rsanders]

Why do you assume that any coins were in cold storage? That's just another unverifiable assertion.

[nwh]

Gox mentions this on a number of occasions, not the least in 2011 when they detailed how their cold storage system worked with split keys.

[jonknee]

Gox also mentioned a lot of stuff before it went dark with everyone's coins. Something obviously went horribly different than planned.

[dsrguru]

In fairness, it's somewhat likely that everything went exactly as planned, at least for some of the people behind MtGox.

[M4v3R]

Thank you for the reply. I don't have any proof for the automatic reissuing on hand at this moment, I've read about it on Bitcointalk forums where several people claimed that they observed this behavior.

[kordless]

Agreed. It's known that Mt. Gox was auto-retrying sends after the txids didn't match.

FWIW, I submitted the 'what most likely happened' post last night: https://news.ycombinator.com/item?id=7328219. It's a bit shorter and seems less speculative.

[waterlesscloud]

Can you link to evidence they auto-retried? Last I'd seen it required contacting their customer service for a manual re-send.

[kordless]

I've read it several places, but don't know the exact source of the information. It's mentioned in this article on the Guardian: http://www.theguardian.com/technology/2014/feb/27/how-does-a...

[nwh]

Definitely agree on both points, though I'm not convinced malleability has anything to do with their current troubles. They might have lost a few Bitcoin with that trick but it's nothing against half a billion dollars.

[nadaviv]

> since they had no reason to use raw transactions API which lets you to use specific inputs, and instead they probably just used the more common sendto API

There's a very good reason to use specific inputs - the only correct way to re-issue transactions is with the same inputs from the failed transaction, ensuring that its impossible for both the old failed transaction and the new one to both exists on the same blockchain.