Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.113 as permitted sender)
	client-ip=62.13.149.113; envelope-from=pete@petertodd.org;
	helo=outmail149113.authsmtp.com; 
Date: Sun, 18 Aug 2013 20:13:57 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130819001357.GA4281@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Bitcoin-development] Bloom io attack effectiveness
Precedence: list


--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

--=20
'peter'[:-1]@petertodd.org

--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJSEWNFAAoJECSBQD2l8JH7HWQH/jXQSMEz/0keD0UeLyJp4sxa
y76nowNt/tszTqyFaKWI+/LY8TfjU05WZRlUS1bm0ZP2zm2iYPQoYlIINncCjLT3
lS8Ht+fICrGKhk1bPA5g2sqZFjwxVsxOxX+tc8i1yxmj0UWUtyx5GGd03LCqryBS
IZK3TFXW1Jg6xMO47+ZMV/PVLuKCGr4v7xWcJIMqFlfVkdW8TI/AgAmQwOgeWnY1
taIwSgvfbH/ysOZDjCBRB5FjFU/UzuCcrCOAo1Ch3M/Nh76DEpu/3thxYKJ9pcSN
g8JuyE9YR3Zd1bh/9t6Z6A4nN0Os8d5PCh9rmA9r55UDl/phK85Dbeoaz5wJ4BY=
=+BJY
-----END PGP SIGNATURE-----

--OXfL5xGRrasGEqWY--