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
131
132
133
134
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UZUax-0002BH-Jx
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 23:13:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.173 as permitted sender)
client-ip=209.85.217.173; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f173.google.com;
Received: from mail-lb0-f173.google.com ([209.85.217.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZUaw-0002KW-G8
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 23:13:23 +0000
Received: by mail-lb0-f173.google.com with SMTP id t10so100020lbi.18
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 May 2013 16:13:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.116.113 with SMTP id jv17mr8903450lab.35.1367881995787;
Mon, 06 May 2013 16:13:15 -0700 (PDT)
Received: by 10.112.35.43 with HTTP; Mon, 6 May 2013 16:13:15 -0700 (PDT)
In-Reply-To: <20130506225146.GA6657@netbook.cypherspace.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
<20130506161216.GA5193@petertodd.org>
<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
<20130506163732.GB5193@petertodd.org>
<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
<20130506180418.GA3797@netbook.cypherspace.org>
<CAAS2fgSh+dYxSak8HvE0Sr4=zxzRc=3dMQ6X_nD_a+OdacUBZQ@mail.gmail.com>
<20130506225146.GA6657@netbook.cypherspace.org>
Date: Mon, 6 May 2013 16:13:15 -0700
Message-ID: <CAAS2fgQU5yHFEUfzVwco=L2YKU=Ci0Od+4w59o1wx5UUf1w3VQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Adam Back <adam@cypherspace.org>
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: 1UZUaw-0002KW-G8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was:
Discovery/addr packets)
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: Mon, 06 May 2013 23:13:23 -0000
On Mon, May 6, 2013 at 3:51 PM, Adam Back <adam@cypherspace.org> wrote:
> Maybe I could hack a pool to co-opt it into my netsplit and do the work f=
or
> me, or segment enough of the network to have some miners in it, and they =
do
> the work.
Or you can just let it mine honestly and take the Bitcoins. This is
fast (doesn't require weeks of them somehow not noticing that they're
isolated), and yields the values I listed as 'costs' if you would have
otherwise been able to use it to mine the difficulty down to 1. Cost
is just as much foregone income from the alternative attack you could
have done instead.
> nor even topological, nor even
> particularly long-lived.
At least for attacks that drive the difficulty down it does.
If you want to talk about abusing a pool or creating a partition in
order to create short reorgs=E2=80=94 I agree, those don't have to be long
lived and you can find many messages where I've written on that
subject.
It's inconsiderate to propose one attack and when I respond to it
changing the attack out from under me. :( I would have responded
entirely differently if you'd proposed people segmenting the network
and creating short reorgs instead of mining the difficulty down.
> Do you know if there is any downwards limit on difficulty? I know it tak=
es
> going slow for a long and noticeable time, but I am just curious on the
> theoretical limit.
Every 2016 blocks can at most lower the difficulty by a factor of 4,
thats where the log4 (number of 2016 groups needed) and 4^n (factor in
cost reduction for each group) come from in the formulas I gave
previously.
> I dont see the signatures.
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256S=
UMS.asc/download
The signatures can't be inside the tarball because they sign the tarball.
Seems like the website redesign managed to hide the signatures pretty
good. They're in the release announcements in any case, but that
should be fixed. Even when they were prominently placed, practically
no one checked them. As a result they are mostly security theater in
practice :(, =E2=80=94 so=E2=80=94 unfortunately, is SSL: there are many CA=
's who will
give anyone a cert with your name on it who can give them a couple
hundred bucks and MITM HTTP (not HTTPS!) between the CA's
authentication server and your webserver. Bitcoin.org is hosted by
github, even if it had SSL and even if the CA infrastructure weren't a
joke, the number of ways to compromise that hosting enviroment would
IMO make SSL mostly a false sense of security.
The gpg signatures and gitian downloader signatures provide good
security if actually used, solving the "getting people to use them"
problem is an open question.
And I agree, this stuff is a bigger issue than many other things like
mining the difficulty down.
|
