[or-cvs] work out a few more details of the dirserver-based reputation

[arma at seul.org]

Update of /home2/or/cvsroot/tor/doc
In directory moria:/home/arma/work/onion/cvs/tor/doc

Modified Files:
	incentives.txt 
Log Message:
work out a few more details of the dirserver-based reputation
scheme.


Index: incentives.txt
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/incentives.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -d -r1.5 -r1.6
--- incentives.txt	12 Feb 2006 10:34:31 -0000	1.5
+++ incentives.txt	13 Feb 2006 10:43:29 -0000	1.6
@@ -271,22 +271,29 @@
    directory to see if they really do offer roughly the bandwidth
    they advertise. Include these observations in the directory. (For
    simplicity, the directory servers could be the measurers.) Then Tor
-   servers weight priority for other servers depending on advertised
-   bandwidth, giving particularly low priority to connections not
-   listed or that failed their spot-checks. The spot-checking can be
-   done anonymously to prevent selectively performing only for the
-   measurers, because hey, we have an anonymity network.
+   servers give priority to other servers. We'd like to weight the
+   priority by advertised bandwidth to encourage people to donate more,
+   but it seems hard to distinguish between a slow server and a busy
+   server.
+
+   The spot-checking can be done anonymously to prevent selectively
+   performing only for the measurers, because hey, we have an anonymity
+   network.
 
    We could also reward exit nodes by giving them better priority, but
    like above this only will affect their first hop. Another problem
    is that it's darn hard to spot-check whether a server allows exits
-   to all the pieces of the Internet that it claims to. A last problem
-   is that since directory servers will be doing their tests directly
-   (easy to detect) or indirectly (through other Tor servers), then
-   we know that we can get away with poor performance for people that
-   aren't listed in the directory. Maybe we can turn this around and
-   call it a feature though -- another reason to get listed in the
-   directory.
+   to all the pieces of the Internet that it claims to. If necessary,
+   perhaps this can be solved by a distributed reporting mechanism,
+   where clients that can reach a site from one exit but not another
+   anonymously submit that site to the measurers, who verify.
+
+   A last problem is that since directory servers will be doing their
+   tests directly (easy to detect) or indirectly (through other Tor
+   servers), then we know that we can get away with poor performance for
+   people that aren't listed in the directory. Maybe we can turn this
+   around and call it a feature though -- another reason to get listed
+   in the directory.
 
 5. Recommendations and next steps.