Thank you, that made things more clear, is there a link to the routing paper? regards leo
On Fri, Jun 19, 2009 at 6:01 PM, Christian Grothoff <[email protected]>wrote: > On Friday 19 June 2009 09:11:30 am leo stone wrote: > > Hi Christian, > > thanx for the link. I've read it and except from a few other questions > > there is one I can't get my head around. > > > > Maybe you can explain this better to me. > > > > Let's call this the "I'd like to help but they don't let me 'cause they > > don't trust me" syndrome. > > > > I consider following situation: > > > > A new node is willing to participate and connects to the net where all > > nodes have already accumulated a lot of trust to each other. > > > > A->10000000 > > B->10000000 D? <- 0 E (new) > > C->10000000 > > > > If the algorithm in each node is : delegate to the node wich gives me > > potantially the best results, ergo choose > > the ones i trust most > > 1) Trust is not symmetric, so the node you trust most may not trust you > at all; in fact, the protocol does not allow you to find out (with any > reasonable amount of precision) how much anyone else trusts you. > > 2) Delegation to nodes that give you potentially the best results is a > routing > decision (different paper); that routing decision does not even consider > trust (and while it does consider recent success rates as one of the > factors, it also considers available bandwidth and each connected node > is assigned a certain minimum share, so E would at least get some > (possibly small) fraction of the queries, giving E the chance to prove > itself. > > > how will the new node ever get a chance to serve any request, and so be > > able to build up trust??? > > and if it's actually possible how long will it take node E to become > > competitive? Will node E not give up before that? > > E does not have to be "competitive" unless A/B/C are actually exhausting > available resources at D at the same time. > > > If i imagine what happens if such a system evolves over time it develops > > disjoint "bubbles of trusting nodes", which will reflect pretty much the > > time when the have joined the network and so had the same trust level and > > so were willing to delegate to each other. > > Unlikely. What we do see is that some nodes end up having very high trust > values because they never use trust that they have earned (servers that are > running, contributing but never issuing any requests on their own). But > those > high trust values don't matter since they are never spent. It's like Bill > Gates theoretically being able to buy up all of the bread in the world > causing > everyone else to starve; but since he doesn't actually spent (a significant > amount of) his money, it doesn't matter in practice. > > > This is actually what happens in real life as well, the longer a trusting > > circle exists the harder it becomes to get in except they have some > counter > > mechanism. But usually it is intended to keep a trusting circle small. > > Trust is not used to determine who peers connect to, and since trust is > also > not used to determine who gets requests (since the relevant trust direction > is > not known), those circles don't actually form. > > Best, > > Christian > > > > Please explain to we what I didn't get right. tx > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 19, 2009 at 4:08 AM, Christian Grothoff > > > > <[email protected]>wrote: > > > Hi Leo! > > > > > > Well, the primary resource for the economic system is the paper on the > > > subject, which you can find at > > > > > > http://gnunet.org/download/ebe.pdf > > > > > > (much more readable then trying to get it out of the code). Also, in > > > contrast > > > to the ECRS paper, this paper is actually up-to-date with what the code > > > is doing. > > > > > > Now, you say you "wonder if this part of gnunet was ever questioned" -- > > > that's > > > a bit harder to answer; obviously quite a few people have thought about > > > it and > > > asked questions, and there are quite a few good open questions in this > > > context. However, I am not aware of a well-reasoned suggestion for > > > improvement at this point. The two major research questions that stand > > > out for me are: > > > > > > 1) How can we give the user feedback to make him *feel* that by earning > > > trust > > > he is getting better service? While this may seem like a UI issue, > > > related issues such as gathering the speed-up data (how much speed-up > was > > > obtained) and making it significant (maybe the benefit is not large > > > enough to begin with?) without compromising the overall security > > > properties would also be addressed to get the main issue resolved. > > > > > > 2) How should we set prices? The paper gives some basic constraints on > > > how peers should set prices, but it doesn't give anything near a > > > closed-form answer for price-formation. The code currently uses > > > heuristics which lack proper justification for why they are good or > even > > > optimal. Having a better > > > pricing mechanism (how much a peer offers for content, when, how often, > > > etc.) > > > would likely help with question (1) by presumably making the speed-up > > > more dramatic. Evaluation methods I'd accept here range from complete > > > mathematical > > > models to (good) simulations. > > > > > > Both of these questions have been raised many times over the years by > > > myself > > > and others. I think skilled researcher with enough time and energy > could > > > most > > > likely find a reasonable answer for (2); gathering speed-up data > without > > > leaking information that might harm anonymity and/or some of the > economic > > > principles sounds like a really hard problem (on the economic side, > > > sharing speed-up information is like giving a buyer information on the > > > profit-margin > > > of a store without giving the buyer a reason (and data) for negotiating > > > harder > > > for the next purchase...). So I'm much less optimistic on finding a > > > solution > > > on (1) short of improving (2) to the point that the speed up is > > > "obvious". > > > > > > As far as GNUnet growing, I am not sure this is the primary issue; > > > ease-of-use > > > (including initial installation) and speed and scalability of the basic > > > routing algorithm (which is improving slowly over time, but still not > > > quite where I'd like it to be) are likely more relevant to overall > > > growth. Naturally, having good answers to the above two questions would > > > also help. > > > > > > Christian > > > > > > On Thursday 18 June 2009 01:03:48 pm leo stone wrote: > > > > Hi All, > > > > > > > > since there are pretty big changes ahead for 0.9 maybe it's just the > > > > > > right > > > > > > > moment to raise a few > > > > questions regarding the economic system. since i hadn't a look at the > > > > > > code > > > > > > > i know nothing > > > > about it, except a blurry idea that a node prefers to serve nodes it > > > > > > trusts > > > > > > > most. how this trust builds up and on what it is based is unclear to > > > > me. but before i start formulating any thoughts i'd like to > understand > > > > the current implementation. > > > > are the any other sources except the code to grasp all the details? > > > > > > > > what i wonder is, if this part of gnunet was ever questioned? > > > > > > > > i really feel that right there could be the main cause that gnunet > > > > didn't grow as all the people would like to see > > > > it growing. but before i can start any argument i should first know > > > > what > > > > > > i > > > > > > > am talking about so please > > > > point me to any available resource, explain it to me or tell me if > the > > > > > > only > > > > > > > source is the code. > > > > > > > > thx > >
_______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
