Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZZpt-0002Ws-4h for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 04:49:09 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of praus.net designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; envelope-from=petr@praus.net; helo=mail-la0-f43.google.com; Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZZpr-00005s-2m for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 04:49:09 +0000 Received: by mail-la0-f43.google.com with SMTP id ea20so136749lab.30 for ; Mon, 06 May 2013 21:49:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=6Mrfh0EhPDuWfdR32jsXw6FTfdqf8muzKvvtkBXAiIU=; b=kvMOE97FJpI8mJYdiB23ME/YJQDQvTKH0zTSq7+HhG3mhi6cVVSa6GDcgYcmwjCzFJ J4pidqDtpS7tPnfrMCSfjlEKT7YQ0xyjnaGifHZLQC8/G2X/yRvielow0xQk31RMQJx6 WIgbAjDl0lScdcOZIo0R8FUF7tgFXWHJSKcxa9g1orY+0DtFbWmVoO4vwSdkQlDRTReC JqaQjEBKD/W3KFxhYhqpe3vFGbTQe8vGbFs8Pxqx8yyNkpmf3U7n5Qb4w78jhJw7cVfD TdeNNx0ISIYufe6wVLeyi8FY8aR5j557AEXO/Pva8bhSQJG5ibn+eU2aceHebIdH3Otw uAvg== X-Received: by 10.112.168.197 with SMTP id zy5mr328518lbb.18.1367902139806; Mon, 06 May 2013 21:48:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.201 with HTTP; Mon, 6 May 2013 21:48:39 -0700 (PDT) X-Originating-IP: [216.188.247.150] In-Reply-To: References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> <20130506180418.GA3797@netbook.cypherspace.org> <20130506225146.GA6657@netbook.cypherspace.org> From: Petr Praus Date: Mon, 6 May 2013 23:48:39 -0500 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a11c23f1c2184f404dc1989b9 X-Gm-Message-State: ALoCoQnLcClN80ZLNgJBsujHWCgAX+ksRaIuyQpGyC0QPodWZBoa+GSECSdxeMlkNhCJz1Q9QPoT X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1UZZpr-00005s-2m 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: Tue, 07 May 2013 04:49:09 -0000 --001a11c23f1c2184f404dc1989b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it's worth noting that quite a large portion of Linux users probably get the mainline Bitcoin client from the packages. I think Bitcoin package maintainers are doing mostly a pretty good job :) On 6 May 2013 18:13, Gregory Maxwell wrote: > 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 > for > > me, or segment enough of the network to have some miners in it, and the= y > 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 lon= g > 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 > takes > > 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/SHA25= 6SUMS.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. > > > -------------------------------------------------------------------------= ----- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c23f1c2184f404dc1989b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it's worth noting that quite a large portion o= f Linux users probably get the mainline Bitcoin client from the packages. I= think Bitcoin package maintainers are doing mostly a pretty good job :)


On 6 May 2013= 18:13, Gregory Maxwell <gmaxwell@gmail.com> wrote:
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 wor= k for
> me, or segment enough of the network to have some miners in it, and th= ey 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 h= ave
otherwise been able to use it to mine the difficulty down to 1. =C2=A0Cost<= br> 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 l= ong
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. :( =C2=A0I 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? =C2=A0I kno= w it takes
> going slow for a long and noticeable time, but I am just curious on th= e
> theoretical limit.

Every 2016 blocks can at most lower the difficulty by a factor of 4,<= br> 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/SHA256SUMS.asc/download
The signatures can't be inside the tarball because they sign the tarbal= l.

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. =C2=A0Even when they were prominently placed, practically<= br> 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<= br> 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&quo= t;
problem is an open question.

And I agree, this stuff is a bigger issue than many other things like
mining the difficulty down.

---------------------------------------------------------------------------= ---
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases = and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c23f1c2184f404dc1989b9--