Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WCs1r-0007cJ-Oq for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 14:40:11 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WCs1p-00015j-MS for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 14:40:11 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 2BDCCDDAEFC; Mon, 10 Feb 2014 15:40:03 +0100 (CET) To: Bitcoin Dev From: Isidor Zeuner In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20140210144003.2BDCCDDAEFC@quidecco.de> Date: Mon, 10 Feb 2014 15:40:03 +0100 (CET) X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WCs1p-00015j-MS Subject: Re: [Bitcoin-development] MtGox blames bitcoin 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 14:40:11 -0000 > > What is the official response from the Bitcoin Core developers about > MtGox's assertion that their problems are due to a fault of bitcoin, as > opposed to a fault of their own? > > The technical analysis preluding this mess, was that MtGox was at fault for > their faulty wallet implementation. > I'm not a core developer, but I would certainly hope that those who have commit access to the Bitcoin repository don't let themselves be pressured by a company holding back user funds in order to get a patch included into the Bitcoin source code. I think this is less a matter of whose fault it is if a company running a custom wallet implementation has problems peering with a network mostly running another, community-based wallet implementation. It is a matter of common sense that it's just not practical to try to quickly apply an update to a distributed network, which may possibly cause problems with peering and consensus finding. When working with a protocol based on mutual agreement of a large user base, a single entity like MtGox would be better off trying to have their preferred changes implemented slowly if at all, while solving their immediate issues on their side. Problems with transactions being accepted can often be solved by changing the wallet client's way of peering with other nodes, without changing the protocol at all. Thinking this further, I am kind of surprised that something like this can even become an issue worth discussing. I never heard of a bank which would try to create pressure by suspending money withdrawals until the TCP/IP protocol is changed to match their preferences. Best regards, Isidor Zeuner