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
|
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 <gmaxwell@gmail.com>) id 1Us9zq-0006fJ-Pm
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Jun 2013 11:04:15 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.170 as permitted sender)
client-ip=209.85.217.170; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f170.google.com;
Received: from mail-lb0-f170.google.com ([209.85.217.170])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Us9zp-0005y1-1W
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Jun 2013 11:04:14 +0000
Received: by mail-lb0-f170.google.com with SMTP id t13so328487lbd.29
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Jun 2013 04:04:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.141.202 with SMTP id rq10mr3940806lbb.83.1372331046281;
Thu, 27 Jun 2013 04:04:06 -0700 (PDT)
Received: by 10.112.160.104 with HTTP; Thu, 27 Jun 2013 04:04:06 -0700 (PDT)
In-Reply-To: <51CC12A6.3090100@inf.ethz.ch>
References: <51CC12A6.3090100@inf.ethz.ch>
Date: Thu, 27 Jun 2013 04:04:06 -0700
Message-ID: <CAAS2fgRg8B_j=Luf31R8-+vqOWQOUcUDof8wdq79_Ar9YuUm9g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Arthur Gervais <arthur.gervais@inf.ethz.ch>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Us9zp-0005y1-1W
Cc: Ghassan Karame <ghassan@karame.org>,
bitcoin-development@lists.sourceforge.net,
Hubert Ritzdorf <rihubert@inf.ethz.ch>
Subject: Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin
due to Client versions 0.8.1
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: Thu, 27 Jun 2013 11:04:15 -0000
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais
<arthur.gervais@inf.ethz.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear Bitcoin developers,
>
> We would like to report a vulnerability which might lead, under some
> assumptions, to a double-spending attack in a fast payment scenario.
> The vulnerability has been introduced due to signature encoding
> incompatibilities between versions 0.8.2 (or 0.8.3) and earlier
> Bitcoin versions.
>
> Please find at the following link a detailed description of this
> vulnerability:
> ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf
It would be kind if your paper cited the one of the prior discussions
of this transaction pattern:
E.g. https://bitcointalk.org/index.php?topic=196990.msg2048297#msg2048297
(I think there are a couple others)
The family of transaction patterns you describe is one of the ones I
specifically cite as an example of why taking non-reversible actions
on unconfirmed transactions is unsafe (and why most of the Bitcoin
community resources) council the same. You can get similar patterns
absent changes in the IsStandard rule through a number of other means.
One obvious one is through concurrent announcement: You announce
conflicting transactions at the same time to many nodes and one
excludes another. By performing this many times and using chains of
unconfirmed transactions and seeing which family your victim observes
you can create input mixes that are only accepted by very specific
subsets of the network.
|
