Topic: Why support Tor Hidden Services (Read 1605 times)

The upcoming 0.7 release will support running as a hidden service, and supports hidden services finding each other via the p2p and dnsseed peer-finding mechanisms; see
   https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt  for information.

you guys are using the wrong terms, a hidden service is for servers, and tor is the network. If your going to run a node of bitcoind which is different from the bitcoin-qt then you would use the hidden service. If you want to connect bitcoin-qt to the network thru tor then use tor as the proxy. You can connect to the bitcoin-qt to the tor network, just beware of the DNS leak. Just in the future it will be more stable and integrated.

I'm not worried.  Today atleast, but when bitcoin takes off who knows what isp filtering they will use to block it.  Also, i thought it wasn't currently possible to run Bitcoin thru a hidden service.  But that function is coming soon, right?

If you're worried about your ISP knowing you run Bitcoin then operate your node as a Tor hidden service.

If you're worried about Tor being blocked then combine your efforts with all the other people who are working on making Tor harder to block in order to have maximum effectiveness.

Remember bittorrent is a full company, bitcoin is dev for free, they have to pick and choose there battles, and I think tor fixes that problem the most optimum way, with the resources they have.

I totally get that.  i was asking more philosophical question.  Probably something for Version 0.9 or 1.0.   Look we all know that sooner or later Bitcoin will be blocked by some country or isp, somewhere in the world.  Right now my ISP knows i run Bitcoin, if they are inspecting packets at all, which in many privacy dead societies they do just that.  Alls i'm saying is isn't it easy to block the traffic then?  And thus shouldn't the basic client, regardless of how it discovers peers, mask the traffic to look like bittorrent or tor?  In bittorrent there is a feature to encrypt all packets, which supposedly helps evade throttling.

Yes, but the focus should be on bitcoin transactions themselves, not the network communication. Tor is already working on anonymized network communications so the best division of labor is to use Tor to protect the network communications and let the Bitcoin developers focus on Bitcoin-specific problems.

DNS:  I'm not sure why bitcoin ever *needs* to do a dns lookup.  Right now i think the ip peer addresses are distributed through some kind of IRC look up (which is where the dns request comes in, right?)  Or am I talking about Bitcoin several versions ago?

If that system is still in use, i can see why Tor hidden services are like an easy drop in.  And of course for onion routing to work, it think you need a distributed list of ips and associated public keys.  At least thats how Tor does it.  By implementing Bitcoin over hidden services you never need to reveal your ip as running a bitcoin client. 

That said regardless of the tor compatibility, doesn't it also just make sense for the legacy client to communicate thru SSL by default, which would make its traffic look like I was either running bittorrent, tor, or an https server, or going crazy buying crap from a dozen different retailers. 

Doesn't Eff's HTTPS Everywhere plugin do this, the idea of creating more an more casually encrypted traffic to 'run cover' for all the 'real' traffic which actually needs it?

Yes, but that dns leak would only reveal the u have a bitcoin client running, not and specific tx you may have initiated.

Its a serious question though: should bitcoin be further anonymized (anonymity hardening?).  I think it should, i'm not sure of all the details, but it does jump out at me that we already have a substanial network.  I"m not talking about relaying actual Tor traffic.  I am talking about the bitcoin network becoming a parallel network, that routes certain activities according to onion-routing principles, namely, initiating txs.

Also, why not encrypt all the traffic between nodes similarly to how Tor does it, thus it will be tough for any one doing network analysis to know whether you are running Bitcoin, Tor, both or some other service.

Well then, why not include anonymization network X or Y ?
I say do one thing and do it well.

I don't want no tor in my bitcoin client, I don't want it to brew coffee either.

As i understand it, the next release of bitcoin will support some ability to publish a hidden service, and distribute that instead of an IP to fellow clients.  Thus the clients will talk to each other thru these hidden services.  But Why?

Tor hidden services have pretty high latencies.  Thats because in order to receive a packet the host has to ask a relay to be his front, and do so behind a hop for anonymity, and the sender already went through another hop to talk to it in the first place.  Thus, both parties of the communication don't know the real ip but it takes 4 hops minimum.  

Is this necessary?  Why not just have the clients encrypt all traffic by default, and when transmitting a new one, have it onion routed with a second layer of encryption so its first transmitted to the rest of the network by a node at least 2 hops away.  With packet level encryption it would be impossible for any one monitoring the network to know exactly what is being sent or who is originating.

If done that way it doesn't rely on Tor, nor absorb any of Tor resources.  What i'm saying is, don't we already have a network of nodes?  Don't they really just need to start encrypting their traffic and doing a bit of their own Onion like routing for new txs?    Unless what i'm describing is somehow much harder to implement.