4 ms·
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 agains
by emin-gun-sirer 13y ago
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.
- rsanders 13y agoWhy do you assume that any coins were in cold storage? That's just another unverifiable assertion.
- nwh 13y agoGox mentions this on a number of occasions, not the least in 2011 when they detailed how their cold storage system worked with split keys.
- M4v3R 13y agoThank 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.
- bashcoder 13y agoGood 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.
- lvs 13y agoAnother 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-attack-hour-by.html http://www.righto.com/2014/02/the-bitcoin-malleability-attac...
- gojomo 13y agoThat'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 13y agoThat 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 13y agoTheir 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_chatter_about_what_is_going_on_at_mtgox/cf99yac 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.
- gojomo 13y agoIt'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 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.