7 ms·

I think that his points against transaction malleability are invalid: - technical one - Bitcoin clients have a 100 ms delay before they relay messages. An atta

by M4v3R 13y ago

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).

nwh 13y ago
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.
kordless 13y ago
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 https://news.ycombinator.com/item?id=7328219. It's a bit shorter and seems less speculative.
- waterlesscloud 13y ago
  Can you link to evidence they auto-retried? Last I'd seen it required contacting their customer service for a manual re-send.
  - kordless 13y ago
    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-bug-in-bitcoin-lead-to-mtgoxs-collapse http://www.theguardian.com/technology/2014/feb/27/how-does-a...
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 ago
  Why do you assume that any coins were in cold storage? That's just another unverifiable assertion.
  - nwh 13y ago
    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 13y ago
      Gox also mentioned a lot of stuff before it went dark with everyone's coins. Something obviously went horribly different than planned.
nadaviv 13y ago
> 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.

by M4v3R 13y ago

nwh 13y ago

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.

kordless 13y ago

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 https://news.ycombinator.com/item?id=7328219. It's a bit shorter and seems less speculative.

waterlesscloud 13y ago
Can you link to evidence they auto-retried? Last I'd seen it required contacting their customer service for a manual re-send.
- kordless 13y ago
  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-bug-in-bitcoin-lead-to-mtgoxs-collapse http://www.theguardian.com/technology/2014/feb/27/how-does-a...

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 ago
Why do you assume that any coins were in cold storage? That's just another unverifiable assertion.
- nwh 13y ago
  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 13y ago
    Gox also mentioned a lot of stuff before it went dark with everyone's coins. Something obviously went horribly different than planned.

nadaviv 13y ago

> 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.