Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Date: Sun, 27 Jul 2014 22:40:30 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy <jlrubin@MIT.EDU>
Message-ID: <20140728024030.GA17724@savin>
References: <CAD5xwhhKKooGBfSY3nZzMmS=3WD=EdX9FQ7mZtQL3fkikuwyLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <CAD5xwhhKKooGBfSY3nZzMmS=3WD=EdX9FQ7mZtQL3fkikuwyLg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, alex@stamos.org
Subject: Re: [Bitcoin-development] Abnormally Large Tor node accepting only
 Bitcoin traffic
Precedence: list


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 27, 2014 at 10:12:11PM -0400, Jeremy wrote:
> Hey,
>=20
> There is a potential network exploit going on. In the last three days, a
> node (unnamed) came online and is now processing the most traffic out of
> any tor node -- and it is mostly plaintext Bitcoin traffic.
>=20
> http://torstatus.blutmagie.de/router_detail.php?FP=3D0d6d2caafbb32ba85ee5=
162395f610ae42930124
>=20
> Alex Stamos (cc'ed) and I have been discussing on twitter what this could
> mean, wanted to raise it to the attention of this group for discussion.
>=20
> What we know so far:
>=20
> - Only port 8333 is open
> - The node has been up for 3 days, and is doing a lot of bandwidth, mostly
> plaintext Bitcoin traffic
> - This is probably pretty expensive to run? Alex suggests that the most
> expensive server at the company hosting is 299=E2=82=AC/mo with 50TB of t=
raffic

Boring explanation: some mining pool wants to get a lower orphan rate by
connecting to the whole network simultaneously and has cleverly setup
their node as a Tor exit node to get some plausible deniability.

Of course, reducing orphan rates is indistinguishable from a sybil
attack; in general setting up such a node can be plausible deniability
cover for any type of attack. One possibility would be to sybil attack
the network to do logging; another would be DoS attacks. For the latter
we're pretty vulnerable to the Bloom IO attack(1). The former attack is
possible too, though I'd expect an attacker to want to do it in a less
obvious way and run more than one node. Also running one big Tor node is
less than ideal as it won't accept incoming connections, which lets you
attack SPV clients. Finally note how you can plausibly conduct the
attack directly from the node itself without bothering to actually use
the Tor network.

Anyway, just goes to show that we need to implement better incoming
connection limiting. gmaxwell has a good scheme with interactive
proof-of-memory - where's your latest writeup?

1) https://github.com/petertodd/bloom-io-attack

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

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

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJT1bgYXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAyMDFkNTA1NDMyZDcwOGFhMmVkYjY1NmY2ZmUzNGQ2ODZi
MzdkNDc0N2U1ZmYzODkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsTvAf/TDD8g1AwmIOFZbVFjodMcYIh
FufBmvANOENBX3yzvXaYgDxCr+uPxkX/m/LkarulqyKpxtIlkLTc18biq/Jh8XON
3SULIdIN/vH5Y3aXT3qhSoxXYGeOGnjOFSvXYuNAsGYW5CiD6mijmeD0g7mgLjdv
QzY9dwnkPIFMD7qmboJL1mj42JnQYVRznDymOwKdsMJ3gDiroCWmQqpJxTfTAbxz
0Byw9w1lgslNxhK5NfVcSwl0D2pmD+7MhAcCwzUqPc7qqYMjbteecY0GRSmvX+O7
au1srQMNSOh0Q4aixfkGHWeE2vRP/VhBiCOrRzIDva2T4Engrb/jYr7vHZXgpQ==
=kW1W
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--