3 ms·

>MtGox was re-issuing coins automatically They worded that very strangely in their statement about it: >This means that an individual could request bitcoins f

by blhack 13y ago

>MtGox was re-issuing coins automatically They worded that very strangely in their statement about it: >This means that an individual could request bitcoins from an exchange or wallet service, alter the resulting transaction's hash before inclusion in the blockchain, then contact the issuing service while claiming the transaction did not proceed. If the alteration fails, the user can simply send the bitcoins back and try again until successful. Emphasis mine. The reference client certainly doesn't do this on spends. Why would gox have implemented it in this way? It doesn't make any sense at all.

sillysaurus2 13y ago
The reference client certainly doesn't do this on spends. Why would gox have implemented it in this way? It doesn't make any sense at all. I've been researching the details of this disaster. Here's what I've gathered. This info came from Greg Maxwell, a bitcoin core developer. He got his information from the owner of MtGox himself: Gox implemented custom wallet software to deal with massive transaction volume. The reference client wouldn't cut it for their purposes. For what it's worth, Greg agrees with the decision to write custom software for high-volume exchanges. It seems pretty likely that other exchanges have also implemented custom bitcoin software stacks. In the scenario where Gox detected that a transaction failed, they automatically reissued the transaction. But that was based on the faulty assumption that the transaction hash couldn't ever mutate. This flaw was exploited to siphon bitcoin out of Gox. This doesn't matter very much for Gox because, conservatively, they've made at least 120k BTC in profits from trade fees. More likely in the range of 400k. So they'll be able to cover the losses. But this means it's entirely possible that other exchanges and web services with custom software stacks were hit hard by the malleability event, just like Gox was. It depends whether they were automatically reissuing transactions. If so, then they probably lost money.

by blhack 13y ago

sillysaurus2 13y ago

The reference client certainly doesn't do this on spends. Why would gox have implemented it in this way? It doesn't make any sense at all. I've been researching the details of this disaster. Here's what I've gathered. This info came from Greg Maxwell, a bitcoin core developer. He got his information from the owner of MtGox himself: Gox implemented custom wallet software to deal with massive transaction volume. The reference client wouldn't cut it for their purposes. For what it's worth, Greg agrees with the decision to write custom software for high-volume exchanges. It seems pretty likely that other exchanges have also implemented custom bitcoin software stacks. In the scenario where Gox detected that a transaction failed, they automatically reissued the transaction. But that was based on the faulty assumption that the transaction hash couldn't ever mutate. This flaw was exploited to siphon bitcoin out of Gox. This doesn't matter very much for Gox because, conservatively, they've made at least 120k BTC in profits from trade fees. More likely in the range of 400k. So they'll be able to cover the losses. But this means it's entirely possible that other exchanges and web services with custom software stacks were hit hard by the malleability event, just like Gox was. It depends whether they were automatically reissuing transactions. If so, then they probably lost money.