gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Economic System


From: leo stone
Subject: Re: [GNUnet-developers] Economic System
Date: Fri, 19 Jun 2009 18:14:13 +0200

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 <address@hidden> 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
>
> <address@hidden>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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]