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

[freehaven-dev] [degs@ceequdee.com: [Freenet-dev] I had a mad idea]



A rudimentary trust system for Freenet?

----- Forwarded message from degs <degs@ceequdee.com> -----

From: "degs" <degs@ceequdee.com>
To: <freenet-dev@lists.sourceforge.net>
Date: Tue, 2 May 2000 09:07:44 +0100
Subject: [Freenet-dev] I had a mad idea

(apologies if this has been sent twice, my machine is misbehaving and the
logs are inconclusive...)

I had a mad idea (feel free to point and laugh...)

Freenet is co-operating system of entities who do not trust trust each
other. The system depends on these entities providing a mutual service
without cheating. The service is allowing other nodes to use your datastore
and bandwidth. A node wants to use the datastore and bandwidth of the other
nodes in Freenet, but (if it is a selfish node) does not want to provide
datastore and bandwidth itself. This is a classic case of iterated
prisoners' dilemma:

co-operation is sharing your datastore and bandwidth in the form of
Data.Replys
defection is exploting another node's datastore and bandwidth in the form of
Data.Requests
(I'm not sure where inserts fit in this scheme - more later)

The payoff for co-operation is a healthy Freenet, full of useful
information.
The payoff for mutual defection is an empty Freenet, full of unsatisfied
leeches.
The payoff for co-operating when the other node is defecting is that your
services are leeched - how you see this outcome depends on how altruistic
you are.

The well-known stratergy for prisoners' dilemma is Tit for Tat.

I propose that nodes should keep a record of the ratio of requests/replys
from each node they hold a refrence to. This ratio can be modified by some
parameters (more later). This ratio can be used to modify the rate at which
messages are dropped (assiming a probablistic replacement for TTL as some
have proposed previously). The ratio is then used to reward nodes which are
a data source and punish nodes which are a data sink. The ratio could be
modified by two parameters: altruism and fuse.

altruism would effect the degree to which the request/reply ratio caused
packets to be dropped.
fuse is the damping factor in a moving average/1 pole filter which determes
how long our fuse/temper is. the higher the damping factor the longer it
takes for changes in the relative rates of request/reply messages to cause
change in our packet dropping behaviour.

If you set altruism to 1.0 and fuse to 0.0 you get pure Tit for Tat. If you
set fuse to 1.0 you are wholly altruistic (current behaviour)

Just a mad idea..


_______________________________________________
Freenet-dev mailing list
Freenet-dev@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

----- End forwarded message -----