From: Peter Todd <pete@petertodd•org>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Bloom io attack effectiveness
Date: Sun, 18 Aug 2013 20:13:57 -0400 [thread overview]
Message-ID: <20130819001357.GA4281@savin> (raw)
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
Did some tests with a varient of attack... In short it's fairly easy to
saturate a node's disk IO bandwidth and when that happens the node
quickly falls behind in consensus, not to mention becomes useless to
it's peers. Note that the particular varient I tried is different, and
less efficient in bandwidth, than others discussed privately.
Bandwidth required to, for example, take out a Amazon EC2 m1.small is
about 1KiB/second, and results in it getting multiple blocks behind in
consensus, or a delay on the order of minutes to tens of minutes. I had
similar results attacking a p2pool node I own that has a harddrive and
4GiB of ram - of course my orphan rate went to 100%
It'd be interesting to repeat the attack by distributing it from
multiple peers rather than from a single source. At that point the
attack could be made indistinguishable from a bunch of SPV wallets
rescanning the chain for old transactions.
In any case given that SPV peers don't contribute back to the network
they should obviously be heavily deprioritized and served only with
whatever resources a node has spare. The more interesting question is
how do you make it possible for SPV nodes to gain priority over an
attacker? It has to be some kind of limited resource - schemes that rely
on things like prioritizing long-lived identities fail against patient
attackers - time doesn't make an identity expensive if the identity is
free in the first place. Similarly summing up the fees paid by
transactions relayed from that peer also fail, because an attacker can
easily broadcast the same transaction to multiple peers at once - it's
not a limited resource. Bandwidth is limited, but orders of magnitude
cheaper for the attacker than a Android wallet on a dataplan.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next reply other threads:[~2013-08-19 0:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-19 0:13 Peter Todd [this message]
2013-08-19 0:59 ` Gavin Andresen
2013-08-19 1:34 ` Peter Todd
2013-08-19 2:53 ` John Dillon
2013-08-19 21:57 ` Wendell
2013-08-19 9:29 ` 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=20130819001357.GA4281@savin \
--to=pete@petertodd$(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