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 <gavinandresen@gmail.com>) id 1Qu3Eh-0008F8-F1
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Aug 2011 14:06:19 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com;
helo=mail-ew0-f47.google.com;
Received: from mail-ew0-f47.google.com ([209.85.215.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qu3Eg-0006DR-Eb
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Aug 2011 14:06:19 +0000
Received: by ewy5 with SMTP id 5so1100308ewy.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Aug 2011 07:06:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.68.5 with SMTP id q5mr426022wfa.107.1313676001449; Thu, 18
Aug 2011 07:00:01 -0700 (PDT)
Received: by 10.142.133.12 with HTTP; Thu, 18 Aug 2011 07:00:01 -0700 (PDT)
Date: Thu, 18 Aug 2011 10:00:01 -0400
Message-ID: <CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.2 (-)
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
(gavinandresen[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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qu3Eg-0006DR-Eb
Subject: [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 14:06:19 -0000
vector76 on the Forums posted this interesting variation on a 'Finney attack' :
https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391
"Let's say I observe the timing of when nodes are broadcasting
transactions and how they are propagating through the network. By
watching for which nodes are earliest to broadcast transactions from
my target, I manage to establish a direct connection to my target.
I use a similar method of watching block broadcasts to establish
connections to most of the mining pools.
Now I create a transaction making a valid, large deposit into my
target. I do not broadcast this transaction but I add it to a block
that I am attempting to mine. I mine solo, just like normal, except
that I have an extra non-broadcasted tx that I am including.
Eventually, I succeed in creating a valid block. I do not broadcast
it immediately, but instead I wait until someone else mines a block,
and when that happens, I immediately broadcast my block to my target.
If my target sees my block before the other block, they will accept
it, and my transaction will have one confirmation. The block chain
has forked, and my target (and possibly other nodes, if my target
relays quickly enough) will believe that my block is the correct one,
while other nodes will believe that the other fork is the correct one.
I immediately request a withdrawal, and my target generates a
transaction sending the large amount of coins to an address I control.
I also double-spend some of the inputs, sending the coins to myself.
The part of the network that did not receive my block first (which
hopefully is most of the miners) will accept this as valid and work to
include it in the next block.
If my block eventually "wins" because enough miners saw my block first
and added onto it first, then I have just made a deposit and
withdrawal, and I lose nothing.
If my block eventually "loses", then the deposit is invalidated. If
the deposit tx was not one of the inputs to the withdrawal
transaction, then the withdrawal is still valid."
-------------------------------
The lessons are "don't accept 1-confirmation transactions" and "try
to be well-connected."
But maybe the deeper lesson is "don't trust information you get from
only one peer." Or maybe "watch for peers that are trying to fool
you."
--
--
Gavin Andresen
|
