Re: [tor-relays] bitcoin adopt a node idea
ja...@icetor.is wrote: > Sorry perhaps I didn't explain well enough. What I was pointing to was > that tor could benefit from the idea of cheaply crowd sponsored relays > that use ansible, chef or puppet to spin up for a month. That the > article is about bitcoin is merely coincidental. No, I got that okay. I was making a tangential point. The juxtaposition of the two projects seemed worth a comment in support of hidden service ideas. And, yes, the notion of crowd-sponsorship of relays is good, although perhaps a feature to encourage longer-term availability might be better. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *or* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bitcoin adopt a node idea
ja...@icetor.is wrote: > This seems pretty damn similiar to something we should be offering for > Tor relays, possibly even exits and bridges (if they only run for a > month at a time). Possibly co-ordinated through the EFF? > > http://www.coindesk.com/adopt-node-project-aims-bolster-bitcoin-network-security/ > Assuming that the relevant bitcoin programs could be taught to talk SOCKS, then it seems that tor hidden services would, in principle if not in performance, be an ideal solution. Running those bitcoin "full" nodes as hidden services might well make them less vulnerable to being shut down by currency counterfeiters (e.g., the Federal Reserve and the central banks of other states, U.S. Dept. of the Treasury). Performance of hidden services, however, are severely constrained by the hidden services protocol, which can slow connection times enough to make one consider USnail as a possible alternative, and the need for circuits of 2n-1 relays, which makes access even slower than normal tor circuits of n relays. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *or* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bitcoin adopt a node idea
Sorry perhaps I didn't explain well enough. What I was pointing to was that tor could benefit from the idea of cheaply crowd sponsored relays that use ansible, chef or puppet to spin up for a month. That the article is about bitcoin is merely coincidental. -J On 06/26/2014 05:35 AM, Scott Bennett wrote: > ja...@icetor.is wrote: > >> This seems pretty damn similiar to something we should be offering for >> Tor relays, possibly even exits and bridges (if they only run for a >> month at a time). Possibly co-ordinated through the EFF? >> >> http://www.coindesk.com/adopt-node-project-aims-bolster-bitcoin-network-security/ >> > Assuming that the relevant bitcoin programs could be taught to talk > SOCKS, then it seems that tor hidden services would, in principle if not > in performance, be an ideal solution. Running those bitcoin "full" nodes > as hidden services might well make them less vulnerable to being shut > down by currency counterfeiters (e.g., the Federal Reserve and the central > banks of other states, U.S. Dept. of the Treasury). Performance of hidden > services, however, are severely constrained by the hidden services protocol, > which can slow connection times enough to make one consider USnail as a > possible alternative, and the need for circuits of 2n-1 relays, which makes > access even slower than normal tor circuits of n relays. > > > Scott Bennett, Comm. ASMELG, CFIAG > ** > * Internet: bennett at sdf.org *or* bennett at freeshell.org * > ** > * "A well regulated and disciplined militia, is at all times a good * > * objection to the introduction of that bane of all free governments * > * -- a standing army." * > *-- Gov. John Hancock, New York Journal, 28 January 1790 * > ** > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] bitcoin adopt a node idea
This seems pretty damn similiar to something we should be offering for Tor relays, possibly even exits and bridges (if they only run for a month at a time). Possibly co-ordinated through the EFF? http://www.coindesk.com/adopt-node-project-aims-bolster-bitcoin-network-security/ -Jason ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is my tor exit relay set up correctly?
Matt, No, I mean every ab initio Tor relay operator. >From my experience getting into Tor and from watching the list it is obvious >that there is quite often a chasm between those with the goodwill to run a >relay and those confident with Linux and Tor jargon/lexicon. Even asking questions on the list is not very useful because it is not really possible to either ask all you need to or to depend on the answers completely if you don't know who's who. The repetitive questions are annoying to some as well. So why not offer reassurance for the security of the Tor network, and confidence and encouragement to the people who might give up? In my case it has been by accident that I have come across some important aspects of torrc settings and now ARM use. It is better to shepherd people consciously than to keep pointing them bluntly to look at the web of links which depends on them understanding. Robert > >> I would like to see that become the standard for checking newboys's >> relays. It makes a lot of sense to collect the whole set of data and >> save tentative questions and possibly wrong answers on this list (by >> well meaning people nonetheless). No one knows what security >> weaknesses exist by accident or omission. This would be a good way to >> do it thoroughly. >> >> Robert > > I'm guessing you are referring to people who ask about their > configuration as opposed to checking every "newboy's" relay? :) > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge clients don't *really* update dynamic bridge IPs from fingerprints?
It may be partially related, in that I've seen it take weeks to gradually gain a new set of clients after an IP change, which is why I think it's so important to not be abandoning all your clients each time but instead let them update their bridge entries to your new address. If you've been up for 2 months and changed your IP in the middle, you probably cut off and abandoned all your clients after a month just when you were starting to get somewhat known, and had to start over from scratch and are just now beginning to build up a fresh client list again. If you typically get a new IP address every month, you may never be able to build up enough clients to see much traffic with the way things currently seem to work. And of course there's a large random factor in just which clients you end up being handed out to. If you end up with mostly just people doing a little web email once in a while, they won't add up to much traffic. I like to watch my bridge's status page on globe.torproject.org to see the traffic history and number of connected clients history graphs, and also the Vidalia "Who has used my bridge?" status (or the bridge-stats file in your bridge's data directory) to get more detailed feedback than just the total bandwidth used. But another issue may be the random luck of the draw of which bridge assignment pool you end up being placed in. As I understand it, to make it harder for threats to find all the bridges and censor them, the bridges are partitioned off into pools which are only assigned to limited subsets of clients via particular distribution methods and client IP address ranges, so that no threat source can find out about bridges outside of the pool they're allowed to pull from. So if your bridge ends up placed in a pool that just doesn't have many clients using it, your info will be handed out that much less often. In the worst case (from the bridge provider's point of view anyway), I believe some bridges are simply held in reserve for emergency use, such as when a common obfuscation plugin becomes censored, so that there's a ready supply of previously unused and therefore uncensored bridges to hand out once Tor figures out how to avoid the new attack method. That's good for the network of course, but I'm afraid it's not very satisfying for the eager bridge provider who's basically left on the bench as a backup in case a first string player gets injured. I suspect there's a lot of churn in that pool as people feel useless and quit bothering to provide the unused bridge. For what it's worth, the globe status page will also show you what pool your bridge has been placed in, which may help reassure (or confirm :( ) that worry. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge clients don't *really* update dynamic bridge IPs from fingerprints?
On Tue, Jun 24, 2014, at 12:40 AM, Rick Huebner wrote: [snip] > Or maybe I'm just totally misreading this, and my own experiences of > losing all my bridge clients on each change aren't typical, but are due > to some other unknown singular issue. How about you other bridge > providers, how many of you are on dynamic IP addresses, and have you > noticed a similar huge drop in traffic after a change, or does your > traffic seem to snap back pretty quickly as it should? I run two bridges (one is obfs3) off my residential connection (I had to stop running a non-exit relay because Hulu and other big sites blacklist tor nodes) and I'd be happy if I had *any* traffic. Over a two-month period, with 1 IP change in the middle, I've probably only passed about 100MB in actual traffic. Sure, I only have about 2MB/s to spare, but I passed several hundred GB as a relay before I quit. Surely after this amount of time, my fingerprint would have been given out a few times. Or are bridges simply not used all that often? There's no problems on my end according to my Tor logs. I know this is barely related to your experience, but I've been curious myself about bridge utilization. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
