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
83
84
85
86
87
88
89
90
91
92
|
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 <bitcoin@olivere.de>) 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 <bitcoin@olivere.de>)
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 <bitcoin@olivere.de>
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 <bitcoin-development@lists.sourceforge.net>
References: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
In-Reply-To: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
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: <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 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
|
