From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> <20130506180418.GA3797@netbook.cypherspace.org> <20130506225146.GA6657@netbook.cypherspace.org> Date: Mon, 6 May 2013 16:13:15 -0700 Message-ID: From: Gregory Maxwell To: Adam Back 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 23:13:23 -0000 On Mon, May 6, 2013 at 3:51 PM, Adam Back 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.