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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <arthur.gervais@inf.ethz.ch>) id 1UsEfi-0002dd-H9
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Jun 2013 16:03:46 +0000
X-ACL-Warn:
Received: from edge10.ethz.ch ([82.130.75.186])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1UsEfg-0006qR-Fr
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Jun 2013 16:03:46 +0000
Received: from CAS21.d.ethz.ch (172.31.51.111) by edge10.ethz.ch
(82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4;
Thu, 27 Jun 2013 18:03:34 +0200
Received: from [10.0.1.2] (192.33.93.28) by mail.ethz.ch (172.31.51.111) with
Microsoft SMTP Server (TLS) id 14.2.298.4;
Thu, 27 Jun 2013 18:03:37 +0200
Message-ID: <51CC6259.3060003@inf.ethz.ch>
Date: Thu, 27 Jun 2013 18:03:37 +0200
From: Arthur Gervais <arthur.gervais@inf.ethz.ch>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <51CC12A6.3090100@inf.ethz.ch>
<CAAS2fgRg8B_j=Luf31R8-+vqOWQOUcUDof8wdq79_Ar9YuUm9g@mail.gmail.com>
In-Reply-To: <CAAS2fgRg8B_j=Luf31R8-+vqOWQOUcUDof8wdq79_Ar9YuUm9g@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [192.33.93.28]
X-Spam-Score: -1.3 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1UsEfg-0006qR-Fr
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 16:03:46 -0000
On 6/27/13 1:04 PM, Gregory Maxwell wrote:
> 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.
>
Thank you for the reference! This is indeed a very interesting issue,
affecting the same Bitcoin version. However we think it is
complementary, since our reported problem has nothing to do with fees,
dust, nor is it necessary to send the two double-spending transaction at
the same time. In our setting, double-spending still works if the second
transaction is sent after minutes (and the first transaction has not yet
been included into a block).
Clearly, we have outlined the limits of the security of
zero-confirmation payments in an earlier work.
Our only intention is to raise the awareness for merchants who have to
accept zero-confirmation transactions. They should be aware of the
signature encoding difference between Bitcoin versions and the possible
consequences.
|
