<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 10, 2014 at 7:47 PM, Oliver Egginger <span dir="ltr"><<a href="mailto:bitcoin@olivere.de" target="_blank">bitcoin@olivere.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I understand this attack someone renames the transaction ID before<br>
being confirmed in the blockchain. Not easy but if he is fast enough it<br>
should be possible. With a bit of luck for the attacker the new<br>
transaction is added to the block chain and the original transaction is<br>
discarded as double-spend. Right?<br></blockquote><div><br></div><div>No, the problem was that the transaction MtGox produced was poorly formatted.<br><br>It wouldn't cause a block containing the transaction to be rejected, but the default client wouldn't relay the transaction or add it into a block.<br>
<br></div><div>This means that transaction stalls.<br></div><div><br></div><div>If the attacker has a direct connection to MtGox, they can receive the transaction directly. <br><br>The attacker would fix the formatting (which changes the transaction id, but doesn't change the signature) and then forward it to the network, as normal.<br>
<br></div><div>The old transaction never propagates correctly.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Up to this point the attacker has nothing gained. But next the attacker<br>
stressed the Gox support and refers to the original transaction ID. Gox<br>
was then probably fooled in such cases and has refunded already paid<br>
Bitcoins to the attackers (virtual) Gox-wallet.<br></blockquote><div><br></div><div>They sent out the transaction a second time. <br><br></div><div>The right solution is that the new transaction should re-spend at least one of the coins that the first transaction spent. That way only one can possibly be accepted.<br>
</div></div></div></div>