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-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UsEpj-0003DT-Ak
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Jun 2013 16:14:07 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.41 as permitted sender)
client-ip=209.85.215.41; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f41.google.com;
Received: from mail-la0-f41.google.com ([209.85.215.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UsEph-0007VL-Im
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Jun 2013 16:14:07 +0000
Received: by mail-la0-f41.google.com with SMTP id fn20so1059099lab.14
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Jun 2013 09:13:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.87.234 with SMTP id bb10mr4580028lab.55.1372349638847;
Thu, 27 Jun 2013 09:13:58 -0700 (PDT)
Received: by 10.112.160.104 with HTTP; Thu, 27 Jun 2013 09:13:58 -0700 (PDT)
In-Reply-To: <51CC6259.3060003@inf.ethz.ch>
References: <51CC12A6.3090100@inf.ethz.ch>
<CAAS2fgRg8B_j=Luf31R8-+vqOWQOUcUDof8wdq79_Ar9YuUm9g@mail.gmail.com>
<51CC6259.3060003@inf.ethz.ch>
Date: Thu, 27 Jun 2013 09:13:58 -0700
Message-ID: <CAAS2fgRkoY_vHXKyyh91Wfm0f_qW6d_FeKzO+mi-WpDRUxtsRw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Arthur Gervais <arthur.gervais@inf.ethz.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: 1UsEph-0007VL-Im
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:14:07 -0000
On Thu, Jun 27, 2013 at 9:03 AM, Arthur Gervais
<arthur.gervais@inf.ethz.ch> wrote:
> 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).
It works just the same for dust based or any other criteria that makes
transactions non-standard=E2=80=94 including the double spending working if
the second transaction is sent minutes after. Exactly the same code is
executed and the same behavior observed for any case of a non-standard
transaction being used to achieve inconsistent forwarding.
> Our only intention is to raise the awareness for merchants who have to
> accept zero-confirmation transactions.
That is great and I'm certainly glad to see people doing that.
Though take care it that your focus on signature encoding differences
doesn't create a misunderstanding. This isn't only an issue with these
particular versions: There is always mining and relay behavior
inhomogeneity in the network. The level of inhomogeneity changes over
time=E2=80=94 I believe its greatest when new reference client software tha=
t
changes IsStandard but it is never zero as there are large miners with
customized acceptance rules (also mempool state also creates
inhomogeneity). The greater inhomogeneity results in higher success
rates which may be important since some service could conceivable only
be profitable exploited with a high enough success rate.
|
