[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
petr at praus.net
Tue May 7 04:48:39 UTC 2013
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 <gmaxwell at gmail.com> wrote:
> On Mon, May 6, 2013 at 3:51 PM, Adam Back <adam at cypherspace.org> wrote:
> > Maybe I could hack a pool to co-opt it into my netsplit and do the work
> > me, or segment enough of the network to have some miners in it, and they
> > 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— I agree, those don't have to be long
> lived and you can find many messages where I've written on that
> 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
> > 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
> > I dont see the signatures.
> 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 :(, — so— 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 at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev