summaryrefslogtreecommitdiff
path: root/6c/f13b676e387e1ed91a546fc4917c54f911d6e6
blob: 5b805e5c565a01622831e315e8348767e2cb5020 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
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 <cryptocurrencies@quidecco.de>) 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 <bitcoin-development@lists.sourceforge.net>
From: Isidor Zeuner <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CANAnSg1LgpHGf-vTV0to1Z7sogf1ic6WTbogEsrQy1wh4C5zfw@mail.gmail.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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