From: Gregory Maxwell <gmaxwell@gmail•com>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
Date: Mon, 6 May 2013 16:13:15 -0700 [thread overview]
Message-ID: <CAAS2fgQU5yHFEUfzVwco=L2YKU=Ci0Od+4w59o1wx5UUf1w3VQ@mail.gmail.com> (raw)
In-Reply-To: <20130506225146.GA6657@netbook.cypherspace.org>
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 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.
next prev parent reply other threads:[~2013-05-06 23:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell [this message]
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back
2013-05-07 12:04 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgQU5yHFEUfzVwco=L2YKU=Ci0Od+4w59o1wx5UUf1w3VQ@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox