Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V49FX-0003e2-DN for bitcoin-development@lists.sourceforge.net; Tue, 30 Jul 2013 12:41:59 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.49 as permitted sender) client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f49.google.com; Received: from mail-oa0-f49.google.com ([209.85.219.49]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V49FW-0002c0-Jq for bitcoin-development@lists.sourceforge.net; Tue, 30 Jul 2013 12:41:59 +0000 Received: by mail-oa0-f49.google.com with SMTP id n16so4518033oag.36 for ; Tue, 30 Jul 2013 05:41:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.141.36 with SMTP id rl4mr22729929oeb.43.1375188113214; Tue, 30 Jul 2013 05:41:53 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Tue, 30 Jul 2013 05:41:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 14:41:53 +0200 X-Google-Sender-Auth: t7boWA1vHUL6RDYUhwnZBS2VGRI Message-ID: From: Mike Hearn To: Bazyli Zygan Content-Type: multipart/alternative; boundary=047d7b339fbffcd24204e2b9ee9d X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V49FW-0002c0-Jq 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 12:41:59 -0000 --047d7b339fbffcd24204e2b9ee9d Content-Type: text/plain; charset=UTF-8 Various ideas are possible: * Use the Tor SOCKS proxy in such a way that it creates a guaranteed independent circuit to a different exit node each time you connect. This gets you back to the slightly stronger clearnet heuristic of "if I saw a bunch of peers announce my tx, then it's probably valid". I don't know if this is possible. * Have a set of hard-coded long term stable hidden peers, that are run by known community members who are not going to collaborate to defraud people. Of course if they're run by people who are well known that rather defeats the point of them being hidden, but you benefit from the fact that the .onion names double as authentication tokens. * Talk the Tor protocol directly and have the app explicitly pick its own diverse set of exit nodes, one per p2p connection. This is likely to be complicated. Last time I looked Tor doesn't provide any kind of library or API. I agree that it's a kind of theoretical attack right now, but then again, I'm not aware of any countries that block Bitcoin either. The thing with Thailand seems like it might be the result of some confusion over who exactly can make laws in that country. I'd be more concerned about Argentina, but we're a long way from ISPs searching for people to arrest by looking for port 8333. Supporting SOCKS (really: blocking sockets) would be a good thing anyway. Using blocking sockets also means we'd get SSL support, so if at some point Bitcoin nodes start supporting SSL we'd be able to use it more easily. --047d7b339fbffcd24204e2b9ee9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Various ideas are possible:

* Use the Tor SOCKS proxy in such a way that it creates a guaran= teed independent circuit to a different exit node each time you connect. Th= is gets you back to the slightly stronger clearnet heuristic of "if I = saw a bunch of peers announce my tx, then it's probably valid". I = don't know if this is possible.

* Have a se= t of hard-coded long term stable hidden peers, that are run by known commun= ity members who are not going to collaborate to defraud people. Of course i= f they're run by people who are well known that rather defeats the poin= t of them being hidden, but you benefit from the fact that the .onion names= double as authentication tokens.

* Talk the = Tor protocol directly and have the app explicitly pick its own diverse set = of exit nodes, one per p2p connection. This is likely to be complicated. La= st time I looked Tor doesn't provide any kind of library or API.

I agree tha= t it's a kind of theoretical attack right now, but then again, I'm = not aware of any countries that block Bitcoin either. The thing with Thaila= nd seems like it might be the result of some confusion over who exactly can= make laws in that country. I'd be more concerned about Argentina, but = we're a long way from ISPs searching for people to arrest by looking fo= r port 8333.

Supporting = SOCKS (really: blocking sockets) would be a good thing anyway. Using blocki= ng sockets also means we'd get SSL support, so if at some point Bitcoin= nodes start supporting SSL we'd be able to use it more easily.

--047d7b339fbffcd24204e2b9ee9d--