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
|
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 1UFTdW-0003xM-9g
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Mar 2013 18:09:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.178 as permitted sender)
client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f178.google.com;
Received: from mail-lb0-f178.google.com ([209.85.217.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFTdS-00062v-0F
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Mar 2013 18:09:18 +0000
Received: by mail-lb0-f178.google.com with SMTP id n1so217563lba.23
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 Mar 2013 11:09:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.125.239 with SMTP id mt15mr14855923lab.26.1363111747104;
Tue, 12 Mar 2013 11:09:07 -0700 (PDT)
Received: by 10.112.96.164 with HTTP; Tue, 12 Mar 2013 11:09:06 -0700 (PDT)
In-Reply-To: <CALf2ePwae8Y0KxYqcZxEk_KZjUcQN=jaAp=QWa20QeZtJU7UAA@mail.gmail.com>
References: <513ED35A.8080203@gmail.com> <201303121210.34515.luke@dashjr.org>
<CALf2ePwae8Y0KxYqcZxEk_KZjUcQN=jaAp=QWa20QeZtJU7UAA@mail.gmail.com>
Date: Tue, 12 Mar 2013 11:09:06 -0700
Message-ID: <CAAS2fgSZfsAbfWqst+DVjKpaJ5dh7u934rp4p=AE8pbni_VSiw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
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: 1UFTdS-00062v-0F
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Some PR preparation
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: Tue, 12 Mar 2013 18:09:18 -0000
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> I don't want to misrepresent what happened, but how much of that was really
> a risk? The block was rejected, but the transactions were not.
Some but not much. If someone flooded a bunch of duplicate
concurrently announcing both spends to as many nodes as they could
reach they would almost certainly gotten some conflicts into both
chains. Then both chains would have gotten >6 confirms. Then one chain
would pop and anyone on the popped side would see >6 confirm
transactions undo.
This attack would not require any particular resources, and only
enough technical sophistication to run something like pynode to give
raw txn to nodes at random.
The biggest barriers against it were people being uninterested in
attacking (as usual for all things) and there not being many (any?)
good targets who hadn't shut down their deposits. They would have to
have accepted deposits with <12 confirms and let you withdraw. During
the event an attacker could have gotten of their deposit-able funds.
On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes <peter@coinlab.com> wrote:
> Can some enterprising soul determine if there were any double-spend attempts?
> I'm assuming no, and if that's the case, we should talk about that publicly.
There were circulating double-spends during the fork (as were visible
on blockchain.info). I don't know if any conflicts made it into the
losing chain, however. It's not too hard to check to see what inputs
were consumed in the losing fork and see if any have been consumed by
different transactions now.
I agree it would be good to confirm no one was ripped off, even though
we can't say there weren't any attempts.
|
