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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was:
	Discovery/addr packets)
Precedence: list

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.