gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Economic System


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Economic System
Date: Thu, 18 Jun 2009 20:08:50 -0600
User-agent: KMail/1.11.2 (Linux/2.6.27-14-generic; KDE/4.2.2; i686; ; )

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]