On Tue, Apr 04, 2006 at 09:41:16AM -0700, Ryan Fugger wrote: > Hi. I just read on Slashdot that you're doing a F2F darknet for > Freenet 0.7, and I see from Oskar Sandberg's papers posted on > freenet.org that you're using the Metropolis-Hastings algorithm for > routing. First of all, congratulations -- I think this is a great > direction for Freenet to be taking. I'm working on a decentralized > currency system (ripple.sf.net) that would operate on a dark network > like the new Freenet, and I think there are many potential > applications for these networks.
Hehe, I thought up darknet currency some time ago, I'm glad somebody *else* is doing it! (For obvious legal and moral reasons, we must not be seen to be directly associated with such things). Maybe we can create a sufficiently powerful plugin API so that you can plug in to our darknet? > > I came across Ian Clarke's and Oskar Sandberg's "Routing in the Dark" > presentation last year and used that approach for a non-distributed > version of my concept (ripplepay.com), but I've struggled to adapt it > to a distributed environment. I haven't been able to find the > following problems I've encountered addressed anywhere: > > * How do you ensure that nodes don't lie to each other during the > switching process in order to gain an advantage in routing (ie, be > more "findable" on the network), to the detriment of routing in the > overall network? That, unfortunately, is a very interesting question, which we have not fully addressed yet. Several options have been proposed. One is to expose the topology of the network, or at least a local part of it. This is not as radical as it sounds as our current implementation of switching does this anyway, admittedly as a side-effect. Further, something like this will be necessary for (reasonably well performing) premix routing, which is necessary to have good resistance to attacks by supposedly trusted peers. Once we have the topology, we can analyse it to see what parts of it are likely to be bogus, and we can enforce swaps. This is not implemented yet on Freenet :). What is implemented is a commit protocol whereby two nodes commit to do a swap if it is appropriate, before revealing their locations and neighbour locations. The problem with this is it cannot be enforced without additional steps, such as the above. I would be delighted to talk to you about this at length, either here, or more appropriately on tech, or on IRC, or in private email. I have CC'd oskar and tech. > > * How do you prevent nodes from simply declaring their most > advantageous routing position from time to time (ie, pretending to > switch with some imaginary node that has the routing location they > want) instead of coming across it honestly by switching with other > nodes? (And would this behaviour, if adopted by all nodes, lead to > all locations collapsing to a single point? Or would it be OK?) Good question, part of the above really. > > * How do you prevent a node from using multiple routing locations, > each with different neighbours, to improve its findability? See above. One thing you can exploit is that it is generally difficult to convince somebody to trust you under two completely different identities; this *may* help to do some network analysis to establish the credibility of a node; I've also thought about some sort of scoring system. > > * How do you prevent nodes from spoofing other nodes' locations as an attack? In a swap request? Only way you can do this is by some sort of enforcement, and with only credible nodes permitted to participate in swapping. All this is very experimental. We do not have any rigorous proof that we *can* fully secure this, and certainly it isn't at the moment. Having said that, the previous version was worse. I am however very interested in ways to secure it, even if they won't be implemented until beta stage... > > This train of thought has led me back to routing by quasi-hierarchical > keywords, like geographical names, shared in common with neighbours, > in combination with statistical analysis of past queries, sort of like > Freenet's ex-poposal "Next Generation Routing". But if you've solved > the problems I've encountered, please tell me about it, as I'd prefer > to use MH for routing. I'd also like to consider building Ripple as > an application on Freenet (right now I'm planning on building on > XMPP). Thanks for your help. The main advantage of using MH is that it can scale almost indefinitely. If you don't need this you're better off with something more well known, more well tested and more well studied. We have a plugin API for things which use the basic Freenet functionality already (fetching stuff, inserting stuff). I have been thinking about an API for apps which deal directly with peers, for things like local filesharing or instant messaging. It might be possible to run your app on this, or we might want to provide a low level plugin interface for stuff that uses routing. > > Ryan Fugger -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060405/019d0044/attachment.pgp>
