From: Adam Back <adam@cypherspace•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
Date: Tue, 7 May 2013 00:51:46 +0200 [thread overview]
Message-ID: <20130506225146.GA6657@netbook.cypherspace.org> (raw)
In-Reply-To: <CAAS2fgSh+dYxSak8HvE0Sr4=zxzRc=3dMQ6X_nD_a+OdacUBZQ@mail.gmail.com>
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote:
>On Mon, May 6, 2013 at 11:04 AM, Adam Back <adam@cypherspace•org> wrote:
>> bitcoins primaryvulnerability IMO (so far) is network attacks to induce
>> network splits, local lower difficulty to a point that a local and
>> artificially isolated area of the network can be fooled into accepting an
>> orphan branch as the one-true block chain,
>
>It currently costs about 2016*25*$120 = six million dollars to
>reduce the difficulty in your isolated fork by a factor of 4.
Well I take your point that you have to produce 2016 blocks, but at a lower
rate. But that doesnt directly translate into my cost, I am thinking pure
network hacking.
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.
I am just thinking $500k/day worth of relatively perfect crime reward is a
lot of motivation for hacking networks. Many routers home and even carrier
are vulnerable to people armed with cisco source code & 0-days. The
netsplit doesnt have to be geographical, nor even topological, nor even
particularly long-lived.
If you control enough people's network routing at a low enough level, you
dont even have to stop transactions, nor do any mining work, just stop
blocks from the netsplit crossing over, and hold that position for say a day
(if your netsplit has 1/24 of network hash rate in it, so the split gets 6
confirmations to reassure the victims) and let the miners do the work. Do
enough transactions to do a big cash out (spend differently on the two
netsplits). Obviously a big and human inattentive pool, dark-miner etc is
the ideal target to put into the netsplit to increase the power while
controlling less nodes.
Malware could do the same thing for clients, dont forget most are running
windows. Malware could also start a miner if none present.
>> maybe even from node first install time.
>
>Protecting against that— making sure any such attack has to start from
>a high difficulty— is, in my opinion, the biggest continued
>justification for checkpoints.
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.
>> (btw I notice most of the binaries and tar balls are not signed, nor served
>> from SSL - at least for linux).
>
>They are signed.
I dont see the signatures.
http://bitcoin.org/en/download
I see no signatures for linux and none in the tarball. There are some
public keys inside the tarball, thats it. Also no SSL. sourceforge support
SSL so you can download that. But bitcoin.org doesnt even answer 443, and
the source forge link is HTTP. But even if the sourceforge link was SSL one
should not serve an SSL download link from an HTTP page, any more than type
a password into an HTTPS form action on an HTTP page. The attacker can just
redirect and the user doesnt know what is legitimate.
Consequently even if there is code signing on the windows exe, the user
doesnt know that, nor who they should be signed by, and as they are served
via HTTP, its bypassable.
I guess by far the easiest way to attack right now (at least linux users) is
just to change the binaries to create a user operated netsplit, or just have
all their wallets empty to you via a mix once the amount gets interesting.
(All attacks hypothetical of course - I'm actually a white-hat type of
person).
Adam
next prev parent reply other threads:[~2013-05-06 22:52 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 ` Adam Back [this message]
2013-05-06 23:13 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Gregory Maxwell
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=20130506225146.GA6657@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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