[tahoe-dev] switching from introducers to gossip?

[erpo41 at gmail.com]

For what it's worth, I choose not to run both tahoe and tor at the same
time. Both provide services to other people, and the quality of those
services is in large part determined by how much upstream bandwidth I let
them consume. On a 1mbit upstream home cable connection, I would rather
provide one good service than two poor ones.

Thanks,
Eric
 On Jul 10, 2012 4:38 AM, "Greg Troxel" <gdt at ir.bbn.com> wrote:

>
>   It seems people are only aware of the last feature because of the
>   poorly chosen name.  IMO, the "hidden" aspect is one of the less
>   interesting features.  I've heard a rumor that there's a proposal to
>   make a version of this feature which provides the other features
>   without the hidden part for the benefit of lower latency.
>
>
> An important point is that hidden services consume resources on other
> people's systems, and those systems are volunteered for the purpose of
> providing anonymity.  The use of bittorrent is discouraged over tor, not
> because of philosophical objections, but because the tor network can't
> really handle the load.  So while I think tahoe-lafs should work over
> tor, I don't think it's entirely responsible (to the set of people that
> volunteer tor relays) to suggest routine use of tor merely for firewall
> traversal.
>
> That said, it seems connecting to hidden services doesn't require exit
> relay use, so hidden services tread more lightly on the really scarce
> resource; non-exit relays are much easier to come by.
>
>   As for connection capability: onion addresses are an 80 bit substring
>   of a public key hash, so that's 80 bits of unguessable [1].  The
>   design doc [2] does not mention a goal such as "undiscoverability"
>   which would be necessary for capabilities (ie: You can only learn an
>   onion by generating one or being told one out of band, but not by
>   sniffing tor introducer or directory service traffic).  However, from
>   chatting with tor devs I believe this may be an implemented feature.
>   I'm still browsing source code and specs to see if that's true.
>
> My gut feeling is that it's a bad idea to use tor addresses as
> capabilities in a system that needs capabilities from other transports.
> Instead, I would treat onion addresses simply as addresses.  I see the
> point about perhaps eking out a bit of efficiency, but I think it adds
> complexity, fragility, and testing difficulty that greatly outweight the
> win.
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120710/d416f6a7/attachment.html>