Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WCxlg-0004rn-L4 for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 20:47:52 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.51 as permitted sender) client-ip=209.85.216.51; envelope-from=tier.nolan@gmail.com; helo=mail-qa0-f51.google.com; Received: from mail-qa0-f51.google.com ([209.85.216.51]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WCxlf-0002kq-PG for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 20:47:52 +0000 Received: by mail-qa0-f51.google.com with SMTP id f11so10270444qae.24 for ; Mon, 10 Feb 2014 12:47:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.151.147 with SMTP id c19mr51227659qaw.86.1392065266192; Mon, 10 Feb 2014 12:47:46 -0800 (PST) Received: by 10.140.91.116 with HTTP; Mon, 10 Feb 2014 12:47:46 -0800 (PST) In-Reply-To: <52F92CE3.7080105@olivere.de> References: <52F92CE3.7080105@olivere.de> Date: Mon, 10 Feb 2014 20:47:46 +0000 Message-ID: From: Tier Nolan To: Bitcoin Development Content-Type: multipart/alternative; boundary=089e0153673eb2197a04f2137300 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WCxlf-0002kq-PG Subject: Re: [Bitcoin-development] Malleability and MtGox's announcement X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:47:52 -0000 --089e0153673eb2197a04f2137300 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 7:47 PM, Oliver Egginger wrote: > As I understand this attack someone renames the transaction ID before > being confirmed in the blockchain. Not easy but if he is fast enough it > should be possible. With a bit of luck for the attacker the new > transaction is added to the block chain and the original transaction is > discarded as double-spend. Right? > No, the problem was that the transaction MtGox produced was poorly formatted. 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. This means that transaction stalls. If the attacker has a direct connection to MtGox, they can receive the transaction directly. 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. The old transaction never propagates correctly. Up to this point the attacker has nothing gained. But next the attacker > stressed the Gox support and refers to the original transaction ID. Gox > was then probably fooled in such cases and has refunded already paid > Bitcoins to the attackers (virtual) Gox-wallet. > They sent out the transaction a second time. 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. --089e0153673eb2197a04f2137300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 10, 2014 at 7:47 PM, Oliver Egginger <bitcoin@olivere.de>= wrote:
As I understand this attack someone renames the transaction ID before
being confirmed in the blockchain. Not easy but if he is fast enough it
should be possible. With a bit of luck for the attacker the new
transaction is added to the block chain and the original transaction is
discarded as double-spend. Right?

No, t= he problem was that the transaction MtGox produced was poorly formatted.
It wouldn't cause a block containing the transaction to be rejecte= d, but the default client wouldn't relay the transaction or add it into= a block.

This means that transaction stalls.

=
If the attacker has a direct connection to MtGox, they can receive the= transaction directly.

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.

The old transaction never propagates correctly.

Up to this point the attacker has nothing gained. But next the attacker
stressed the Gox support and refers to the original transaction ID. Gox
was then probably fooled in such cases and has refunded already paid
Bitcoins to the attackers (virtual) Gox-wallet.

They sent out the transaction a second time.=A0

The right solution is that the new transaction should re-spend at least on= e of the coins that the first transaction spent.=A0 That way only one can p= ossibly be accepted.
--089e0153673eb2197a04f2137300--