From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V4EhI-0006yd-Hm for bitcoin-development@lists.sourceforge.net; Tue, 30 Jul 2013 18:31:00 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.110 as permitted sender) client-ip=62.13.148.110; envelope-from=pete@petertodd.org; helo=outmail148110.authsmtp.com; Received: from outmail148110.authsmtp.com ([62.13.148.110]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V4EhG-0005rN-HY for bitcoin-development@lists.sourceforge.net; Tue, 30 Jul 2013 18:31:00 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r6UIUof8056688; Tue, 30 Jul 2013 19:30:50 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6UIUhxw092066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Jul 2013 19:30:45 +0100 (BST) Date: Tue, 30 Jul 2013 14:30:43 -0400 From: Peter Todd To: Bazyli Zygan Message-ID: <20130730183043.GA32398@petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 2678b90c-f946-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdQIUEkAYAgsB AmUbWl1eU117XWU7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxpk f3tGGl5yfgdGfng+ ZEJnWHIVXkJ9fRR0 Qh1JQ2QCY3phaTUd TRFcflBJcANIexZF bVd/UyIMLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIjkm DxkEEX0FHFEOQCQ1 RwAA X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/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: 1V4EhG-0005rN-HY Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Tor and Bitcoin 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: Tue, 30 Jul 2013 18:31:00 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2013 at 02:01:39PM +0200, Bazyli Zygan wrote: > > I think to support Tor really well [in bitcoinj], we'd need not only to= make SOCKS work, but also add a way to use hidden peers and then try and c= ome up with an anti-sybil heuristic. Unfortunately it's unclear what such a= heuristic would look like. Bitcoin-Qt uses different /16s as a rule of thu= mb when on the clearnet, but no such technique is usable on Tor because by = definition you aren't supposed to know anything about the hidden peers. >=20 > While the scenario outlined seems unlikely, it's best to be prepared... W= hat do you all think? How can this be done properly? There was a good reply to those concerns last time the issue came up: Tor does not act as a particularly effective man in the middle for nodes that support connections to hidden services because while your connections to standard Bitcoin nodes go through your exit node, the routing path for each hidden service peer is independent. Having said that we should offer modes that send your self-generated transactions out via Tor, while still maintaining non-Tor connections. Anyway Sybil attacks aren't all that interesting if you are the one sending the funds, and receivers are reasonably well protected simply because generating false confirmations is extremely expensive and very difficult to do quickly. After all, you always make the assumption that nearly all hashing power in existence is honest when you talk about replace-by-fee among other things, and that assumption naturally leads to the conclusion that generating false confirmations with a sybil attack would take more than long enough that the user would be suspicious that something was wrong long before being defrauded. I'd be surprised if anyone has ever bothered with a false confirmation sybil attack. I wouldn't be the slightest bit surprised if the NSA is recording all the Bitcoin traffic they can for future analysis to find true transaction origins. Which reminds me, again, we need node-to-node connections to be encrypted to at least protect against network-wide passive sniffiing. Regarding usage I would be interested to hear from those running Bitcoin nodes advertising themselves as hidden services. -http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/= msg02438.html tl;dr: Users should be using Tor to preserve their privacy and the MITM risks are minimal to anyone using Bitcoin correctly. (don't trust zero-conf transactions, they are not secure!) > Gregory Maxwell is the person who wrote the hidden service support for bi= tcoind, right? It might be interesting to get his comments here. Yeah, he had the idea of adding .onion addresses of seed nodes along-side the DNS seeds table; that would give an end-to-end MITM-proof channel to a trusted seed who can in turn give an honest view of the network. Ideally those .onion addresses would be of nodes run by the same people as running the existing seeds so that it was clear who was being trusted - I'll write a patch to do this soon with a .onion testnet seed first. (I run one of the testnet DNSSEED seeds and have a small grant from the foundation to do so) Bitcoin relays .onion addresses over the P2P network, so once you are connected you can gain additional peers with addresses that are MITM resistant. Currently there isn't any equivalent to the (weak) anti-sybil properties of IP address range diversity for .onion's, but in the future we'll eventually add node identities and some way to make creating lots of fake identities for a sybil attack expensive. --=20 'peter'[:-1]@petertodd.org 00000000000000321cb1ef9de9c4a6c470c7f88c4b85bcee3a63121e31096fef --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlH4BlMACgkQpEFN739thoyvlgCghiXIyAtAYjsZr2nVJh+9mUDF UUUAnRH8Czs3aaIyh9Q67Bqx7GJKGjQX =46kp -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--