Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WCxGh-0005MB-Jc for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 20:15:51 +0000 X-ACL-Warn: Received: from olivere.de ([85.214.144.153] helo=mail.olivere.de) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WCxGd-0001l8-TK for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 20:15:51 +0000 Received: from ip-178-202-253-17.unitymediagroup.de ([178.202.253.17]:34430 helo=[192.168.88.251]) by mail.olivere.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WCwpZ-0003Ad-AF; Mon, 10 Feb 2014 20:47:49 +0100 Message-ID: <52F92CE3.7080105@olivere.de> Date: Mon, 10 Feb 2014 20:47:47 +0100 From: Oliver Egginger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bitcoin Development References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WCxGd-0001l8-TK 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:15:51 -0000 Am 10.02.2014 13:28, schrieb Pieter Wuille: > Hi all, > > I was a bit surprised to see MtGox's announcement. The malleability of > transactions was known for years already (see for example the wiki > article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, > or mails on this list from 2012 and 2013). I don't consider it a very > big problem, but it does make it harder for infrastructure to interact > with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to > avoid it altogether to make life easier for everyone. Sorry, I'm not a developer, but I have got a question. It's a little bit off-topic and can't maybe answered easy. 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? 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. So far everything is clear. But what I do not understand: Why apparently had so many customers of Gox payment defaults or severely delayed payments? I would imagine that the attacker may have doubled not only his own transaction (maybe for obfuscating the fraud). But then all transfers would still have go through anyway. And a normal customers would have been satisfied. Most people observe only their wallets, I think. What am I missing here? Sorry, is perhaps a silly question. But maybe you can put me on the right track. regards Oliver