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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
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 <tier.nolan@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
<52F92CE3.7080105@olivere.de>
Date: Mon, 10 Feb 2014 20:47:46 +0000
Message-ID: <CAE-z3OUK0_8an3xAt3T1Sb_iFLNy=AWwiKZYnrURg_o=w0dmPg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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: <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:47:52 -0000
--089e0153673eb2197a04f2137300
Content-Type: text/plain; charset=ISO-8859-1
On Mon, 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, 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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Feb 10, 2014 at 7:47 PM, Oliver Egginger <span dir=3D"ltr"><<a href=
=3D"mailto:bitcoin@olivere.de" target=3D"_blank">bitcoin@olivere.de</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As I understand this attack someone renames the transaction ID before<br>
being confirmed in the blockchain. Not easy but if he is fast enough it<br>
should be possible. With a bit of luck for the attacker the new<br>
transaction is added to the block chain and the original transaction is<br>
discarded as double-spend. Right?<br></blockquote><div><br></div><div>No, t=
he problem was that the transaction MtGox produced was poorly formatted.<br=
><br>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.<br>
<br></div><div>This means that transaction stalls.<br></div><div><br></div>=
<div>If the attacker has a direct connection to MtGox, they can receive the=
transaction directly. <br><br>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.<br>
<br></div><div>The old transaction never propagates correctly.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
Up to this point the attacker has nothing gained. But next the attacker<br>
stressed the Gox support and refers to the original transaction ID. Gox<br>
was then probably fooled in such cases and has refunded already paid<br>
Bitcoins to the attackers (virtual) Gox-wallet.<br></blockquote><div><br></=
div><div>They sent out the transaction a second time.=A0 <br><br></div><div=
>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.<br>
</div></div></div></div>
--089e0153673eb2197a04f2137300--
|
