From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VBD6o-0008WH-OB for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 00:14:10 +0000 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; Received: from outmail149113.authsmtp.com ([62.13.149.113]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VBD6n-0004R3-JD for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 00:14:10 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r7J0E33l000483 for ; Mon, 19 Aug 2013 01:14:03 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r7J0DwCi041773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 19 Aug 2013 01:14:00 +0100 (BST) Date: Sun, 18 Aug 2013 20:13:57 -0400 From: Peter Todd To: Bitcoin Dev 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) X-Server-Quench: 3fff9115-0864-11e3-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgx1 IQ0eXVBSFQZ4AR0L BxoUUhg8cANYeX5u ZEFqQHFbVVt/fUFi QwAWEhcGESATMWAb UUdfdE1ReQdOMBwT PAZ2VXIIfGUPYH59 RlY+ZHU7YD4CbXwN GFxcdVtLHEoCQSgW QxcFGH0uGgUMWzk6 JB9uJ1ASEU0NM1s/ N1Y6QjoA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1VBD6n-0004R3-JD Subject: [Bitcoin-development] Bloom io attack effectiveness X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 00:14:10 -0000 --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--