I would like to be an exit for port 8333 only. I have configured my relay to do this, but I am not being listed with the relay flag and do not see any traffic exiting my node (at least not using arm). I saw an FAQ that says this is because you have to exit web traffic to get marked as an exit. I do not wish to do this.
Is there any way to exit just one port?
On 2014-03-17 21:39:05 (+0100), Mike Hearn wrote:
I would like to be an exit for port 8333 only. I have configured my relay to do this, but I am not being listed with the relay flag and do not see any traffic exiting my node (at least not using arm). I saw an FAQ that says this is because you have to exit web traffic to get marked as an exit. I do not wish to do this.
Is there any way to exit just one port?
I just enabled some exit ports in my relay so I have this issue fresh in my mind. If I'm not mistaken, you need to open two of the ports 80, 443 and 6667 to gain the Exit flag, but not having that flag doesn't mean that you're not an exit (ie. I believe that FAQ to be wrong). Initially I didn't open two of that three ports but I saw outgoing connections to some of the accepted ports nevertheless, so I was being an exit node despite not having the flag. Try waiting some days to see if there's some traffic on port 8333. FWIW I check outgoing connections using netstat instead of arm :).
HTH,
If I'm not mistaken, you need to open two of the ports 80, 443 and 6667 to gain the Exit flag
It's in dir-spec.txt as such. Probably under some rationale of making nodes most widely beneficial. I'd think soaking up btc traffic would be useful, if exit traffic stats supported that need... is it 20GB per thick btc client now?, plus ongoing...
but not having that flag doesn't mean that you're not an exit Try waiting some days to see if there's some traffic on port 8333.
The atlas graphs do show traffic for such nodes providing essentially just 8333. They're usable manually, just not automagically by the client I think. I forget how their traffic is picked up.
There are 850+ nodes allowing 8333.
Have you considered running an onion:8333 seed node to both serve btcnet and keep traffic off the exits? There's an index on bitcoin.it for those. And iirc the btc client will learn them over the btcnet then use them within tor.
What is the motivation?
+Roger, as I'm curious as to the rationale.
On Tue, Mar 18, 2014 at 9:12 PM, grarpamp grarpamp@gmail.com wrote:
If I'm not mistaken, you need to open two of the ports 80, 443 and 6667 to gain the Exit flag
It's in dir-spec.txt as such. Probably under some rationale of making nodes most widely beneficial. I'd think soaking up btc traffic would be useful, if exit traffic stats supported that need... is it 20GB per thick btc client now?, plus ongoing...
Yes, and allowing people to exit only Bitcoin traffic seems beneficial in other ways: you're not likely to get abuse reports from just allowing port 8333, so the cost of being an exit for that is much lower. And it'd indeed take bandwidth pressure off other nodes.
but not having that flag doesn't mean that you're not an exit Try waiting some days to see if there's some traffic on port 8333.
The atlas graphs do show traffic for such nodes providing essentially just 8333. They're usable manually, just not automagically by the client I think. I forget how their traffic is picked up.
The globe page for my node shows "exit probability: 0" so I guess I'm indeed not being sent any.
There are 850+ nodes allowing 8333.
Have you considered running an onion:8333 seed node to both serve btcnet and keep traffic off the exits?
Yes but it doesn't get any traffic for reasons I haven't bothered to figure out yet. Anyway we can't run all of Bitcoin over Tor because it'd kill off our (admittedly quite weak) anti-sybil defences.
On Tue, Mar 18, 2014 at 4:20 PM, Mike Hearn mike@plan99.net wrote:
+Roger, as I'm curious as to the rationale.
There was a pretty big thread debate a couple years back about people only wanting to offer cleartext ports being seen as (whether falsely or not) doing it purely so they can cheaply steal content/tokens off the wire. I don't know if the current spec has any commit relation to that.
Yes, and allowing people to exit only Bitcoin traffic seems beneficial in other ways: you're not likely to get abuse reports from just allowing port 8333, so the cost of being an exit for that is much lower. And it'd indeed take bandwidth pressure off other nodes.
Good point regarding lowering potential headache cost for those not wanting that much of it. There's probably value in offering say all ports but 80/443/25/torrent and whatever else is left out of 'reduced'.
The atlas graphs do show traffic for such nodes providing essentially just 8333. They're usable manually, just not automagically by the client I think. I forget how their traffic is picked up.
The globe page for my node shows "exit probability: 0" so I guess I'm indeed not being sent any.
There are 850+ nodes allowing 8333. Have you considered running an onion:8333 seed node to both serve btcnet and keep traffic off the exits?
Yes but it doesn't get any traffic for reasons I haven't bothered to figure
Being an onion there'd be no tor mechanics preventing traffic. It may just be the proportion of IP vs. onion nodes the btc client sees is small so as not to make contact. You can 'setevents stream' and see btc contacting onions. And can -onlynet, -connect, etc the btc client to test.
out yet. Anyway we can't run all of Bitcoin over Tor because it'd kill off our (admittedly quite weak) anti-sybil defences.
In that you presumably have to pay for commercial node farms where tor nodes are free (and more bandwidth limited). On the other hand, abundant crime money will probably be paying for those farms anyway. So this could be mooot.
My motivation comment was if you were doing publishable research or simply production for fun.
On 2014-03-18 21:20:37 (+0100), Mike Hearn wrote:
The globe page for my node shows "exit probability: 0" so I guess I'm indeed not being sent any.
I saw that in my initial "some ports allowed but no Exit flag" period too. So I guess it's actually "exit probability to 80/443/6667 destinations".
On Mon, Mar 17, 2014 at 09:39:05PM +0100, Mike Hearn wrote:
I would like to be an exit for port 8333 only. I have configured my relay to do this, but I am not being listed with the relay flag and do not see any traffic exiting my node (at least not using arm). I saw an FAQ that says this is because you have to exit web traffic to get marked as an exit. I do not wish to do this.
Is there any way to exit just one port?
Your exit policy means that you would allow a stream to exit if a client asked you for it. The trouble is that most Tor clients build their circuits preemptively -- before they know what destination stream they'll be asked to connect to. The Exit flag is an approximation for "probably will be able to handle whatever stream request shows up".
So your relay will actually get used in practice for exiting, in the case where the client doesn't have any currently open, adequately fresh circuits that would allow exit to port 8333. In that case it will make a new circuit, choosing from all exits whose exit policies allow that stream. But so long as things are going smoothly, there should be preemptive circuits around and ready, so this case should be rare.
Another reason for the Exit flag is to help clients do load balancing -- e.g., avoid putting traffic for the first and second hop on relays that probably have other clients putting traffic on them for the third hop.
https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAutho... https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAutho...
In that sense, you actually don't want the Exit flag for your relay, because it would make clients less likely to use you for their first and second hop, because they'd figure you're busy handling exit streams for other people.
The challenge there is that to do this load balancing more accurately, we have to have an accurate model for what total network load to expect for a given exit policy, so clients can take it into account. Since it's hard to know what that model should be in practice (see e.g. http://freehaven.net/anonbib/#cset12-modeling for more discussion there), and also it's especially hard to predict how it should change over time, it seems to me that a really simple approximation is more likely to be robust.
Hope that helps to explain the tradeoffs, --Roger
Thanks Roger, that does indeed clear things up.
For background, I maintain the bitcoinj project which is a widely used Java Bitcoin implementation. We are planning on bundling the Orchid Tor client and switching on Tor by default for Bitcoin wallets that are based on this library, if we can. We'll see how it goes but if the UX impact is not too bad then we might be adding approximately 750,000 to 1M clients after the update fully rolls out everywhere (which would take a while). About half a million of those are Androids that would be waking up at least every 24 hours and sometimes more frequently.
I guess we can tweak Orchid so that it uses port 8333 in the policy rather than the exit flag for selection of its exit nodes. Should not be difficult.
I've looked at the bandwidth graphs and see that since September Tor has been adding more bandwidth capacity than usage, and Bitcoin SPV is low bandwidth anyway so that seems fine. Though I'm curious what happened in September - correlated with Snowden revealing that Tor wasn't cracked yet? But, I couldn't find any graphs of CPU capacity. Seems like the impact of lots of Bitcoin wallets building circuits would mostly be on the CPU side rather than the bandwidth side. Orchid supports NTor so I'm hopeful the impact would be fairly low, perhaps even lost in the noise.
If you have any thoughts, I'd be happy to hear them.
tor-relays@lists.torproject.org
-
David Serrano -
grarpamp -
Mike Hearn -
Roger Dingledine