On Tuesday 23 Jul 2013 09:32:31 Victor Denisov wrote: > > One problem with the yubikey thing is it takes time to deliver them. > > Hence the need to be able to just buy an invite e.g. with BTC. > > I agree that yubikey can't be the only way to introduce core nodes. > There should be a (near) instant method as well. > > > On the level of tunnels - what I would consider real security - it's > > a major unsolved problem in academia. (Tunnel setup on DHTs) > > I'm probably speaking out of my ass now (I promise to read more on it), > but isn't the whole problem here that on DHTs, nodes don't have access > to the complete node pool, so attacker can influence a set of nodes > chosen for the tunnel, making compromised nodes progressively more > likely to be chosen? If this is correct, can't we just side-step this > problem by keeping full node tables in all bootstrap nodes? > > For a million nodes and 1K structure per node (which is probably an > upper estimate), it's just 1G total. I think it can easily be fully > distributed (i.e., without any partitioning) over a set of bootstrap > nodes; when new core nodes contact bootstrap nodes, bootstrap nodes > collectively produce whatever bootstrap information is required (set of > node references for tunneling, location, etc), and update node > information in their tables (like IP address, last seen time, etc).
How does this help with tunnel setup? Also, it's only practical if core nodes have very high uptime; update traffic is the problem for such schemes in practice. > > >>> If you trust your friends less than you trust the jack-boots, > >>> then you probably don't have much to fear from the jack-boots. > >> > >> As I'd mentioned in a previous email, it's not a question of trust > >> as is, it's a question of damage my friend can do to me if he > >> decides to betray my trust. > > > > No. If they can prove that a given IP address at a given time > > uploaded a given illegal file, game over. Or downloaded it, but > > uploaders are worth more. That's the only safe assumption. > > Then neither darknet nor (current) opennet can work - at all. Basically, > I'm trusting my friends to not disclose that I'm running Freenet - but > no more than that. No, anything with proper tunnels can work fine. > > >> I still don't get why it happens. Are torrent clients run by > >> significantly different slice of users? Again: I can reliably > >> demonstrate speeds of *at least* 500 KB/s for any torrent with 10+ > >> peers; with 20 peers, 90% of torrents, taken from all over the > >> world, will max out my internet connection. This indicates average > >> upload speeds of at least 50 KB/s, and probably closer to 100 KB/s > >> (and with most connections being asymmetric in one way or another, > >> we can safely assume that upload bandwidth is the limiting > >> factor). > > > > Because torrent traffic is more bursty than Freenet? I.e. most of the > > time they are idle? > > It's one possible explanation. I wonder if we can get a distribution of > traffic on a node over the applications accessing it? Can I find out > somehow how much physical traffic is associated with, i.e., FMS? This > would be a very interesting stat, IMO. We don't collect that data at present. We could, if we can identify requests associated with FMS. > > VD.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
