Economic System

[leo stone]

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
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[Christian Grothoff]

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
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[leo stone]

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 

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?

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.

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.

Please explain to we what I didn't get right. tx 

  

 

On Fri, Jun 19, 2009 at 4:08 AM, Christian Grothoff <christian@...> 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
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[Christian Grothoff]

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
>
> <christian@...>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
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[leo stone]

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 <christian@...> 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
>
> <christian@...>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
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[Christian Grothoff]

Anonymous routing is described at

http://gnunet.org/download/aff.pdf

Christian

On Friday 19 June 2009 10:14:13 am leo stone wrote:

> 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
>
> <christian@...>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
> > >
> > > <christian@...>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
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[leo stone]

Oh,

>> 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.

here I meant in the sense that D will direct requests with the same chances to E than to the other

longer existing nodes.

But since trust is not used for routing this is irrelevant. 

Basically a node uses trust only to decide if it "opens the letter", in the case it is to busy to open all.

For how it acts upon an opened letter trust doesn't play a role anymore. 

Is that correct?

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers

[Christian Grothoff]

> here I meant in the sense that D will direct requests with the same chances
> to E than to the other
> longer existing nodes.
>
> But since trust is not used for routing this is irrelevant.
>
> Basically a node uses trust only to decide if it "opens the letter", in the
> case it is to busy to open all.
> For how it acts upon an opened letter trust doesn't play a role anymore.
> Is that correct?

Almost.  A node that has multiple replies may send only a few back to a peer
that has low trust and more to a peer that has high trust (where the exact
definition of "a few" and "more" depends on the load of the node and the size
of the individual responses).  Similarly, the query may be forwarded to more
other peers for high-trust inquiries.  But the distinction is always load-
based and for an idle node the result would be exactly the same.

Christian


_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@...
http://lists.gnu.org/mailman/listinfo/gnunet-developers