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
|
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 1Qu5jb-0000UY-Jg
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Aug 2011 16:46:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
helo=mail-qw0-f47.google.com;
Received: from mail-qw0-f47.google.com ([209.85.216.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qu5ja-0007Db-T4
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Aug 2011 16:46:23 +0000
Received: by qwh5 with SMTP id 5so2059200qwh.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Aug 2011 09:46:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.173.207 with SMTP id q15mr761012qaz.278.1313685977411;
Thu, 18 Aug 2011 09:46:17 -0700 (PDT)
Received: by 10.229.114.206 with HTTP; Thu, 18 Aug 2011 09:46:17 -0700 (PDT)
In-Reply-To: <CABsx9T2zpG=M6nkX4W=KrAJAYaTFR25_MLFmwj43+btWanqqsw@mail.gmail.com>
References: <CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com>
<1313681783.14523.79.camel@mei>
<CANEZrP0rXWO51O6wJfQ3r3A6bviZ7zpthJjzZkA0JDC7auBEdw@mail.gmail.com>
<CABsx9T2zpG=M6nkX4W=KrAJAYaTFR25_MLFmwj43+btWanqqsw@mail.gmail.com>
Date: Thu, 18 Aug 2011 12:46:17 -0400
Message-ID: <CAAS2fgQJZ2b-YDZKfmbA-rTtZfmKsP=QBYuYSQbwFdihoQyHsQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qu5ja-0007Db-T4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] From the forums: one-confirmation attack
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, 18 Aug 2011 16:46:23 -0000
On Thu, Aug 18, 2011 at 12:16 PM, Gavin Andresen
<gavinandresen@gmail.com> wrote:
> We could start with an as simple-as-possible "confidence =3D=3D 0 if
> confirmations < 2, otherwise confidence =3D function(#confirmations)"
> and improve it from there.
At the same time, if this causes people to wait less than the 6 blocks
that the software currently waits for before leaving unconfirmed
status then that would be sad.
Simply waiting a number of blocks is an excellent metric and provides
robustness against almost all attack patterns in a way that various
one-off-heuristics can not as it equates to _real difficulty_ (and
real expense (hashing computation, loss of income on the orphaned
blocks)) in a way that can't be faked.
A few weeks back when there was some rumor going around that mybitcoin
lost coin based on some kind of one confirmation attack I described on
IRC a similar attack pattern which had a useful improvement:
* The attacker runs many widely distributed sybil nodes (e.g. using
botnet drones as simple tcp proxies to appear at many addresses). He
takes advantage of the fact the bitcoin won't connect to /16s that
have already connected to it to further isolate nodes.
* By creating normal looking probe transactions which his own nodes
won't forward he detects network partitions which he is able to
create. He searches for a cut which causes there to be at least two
partitions which contain significant mining power.
* He creates two accounts at MoronBank. He doesn't even bother
identifying MoronBank's node. MoronBank will be in one partition or
another. He makes deposits in both partitions, and conflicting
transactions in the opposite partitions, while carefully filtering out
these transactions from crossing the boundary.
(Notably, the network doesn't appear partitioned to everyone else now
because he's still forwarding blocks and transactions unrelated to his
attack=E2=80=94 it only becomes visible once some of his evil transactions =
are
mined)
* After the funds show up in MoronBank he withdraws and drops the partition=
ing.
Only if he has difficulty getting MoronBank into the smaller partition
does he need to bother locating it and attacking it directly.
The bad thing about this attack is that it doesn't require the
attacker to have any hash power at all: he captures miners as
unwilling (or willing but plausibly deniable) participants. The lost
income from orphaned blocks is externalized to the victimized miners
(and since most pools don't pay orphaned blocks out of pocket a pool
operator would be inclined to help out).
The good thing about it is that it's killed dead by nodes adding in a
few manually configured peerings, they don't even really need to be
trusted: You just need to trust that they don't all go to a single
bad-guy conspiracy. At a minimum all major miners should be fully
meshed.
Unfortunately, We don't currently have software for this as addnode
doesn't worry about keeping the links up... and the major pools also
don't seem to be interested in participating.
|
