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 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— 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 > 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/SHA256SUMS.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 :(, — 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >