[or-cvs] checkpoint some more notes on incentives

[arma@xxxxxxxx]

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

Modified Files:
	incentives.txt 
Log Message:
checkpoint some more notes on incentives


Index: incentives.txt
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/incentives.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -d -r1.3 -r1.4
--- incentives.txt	1 Feb 2006 10:50:23 -0000	1.3
+++ incentives.txt	9 Feb 2006 03:44:13 -0000	1.4
@@ -152,6 +152,29 @@
    maybe it's an argument in favor of a more penny-counting reputation
    approach.
 
+3.7. What is the appropriate resource balance for servers vs. clients?
+
+   If we build a good incentive system, we'll still need to tune it
+   to provide the right bandwidth allocation -- if we reserve too much
+   bandwidth for fast servers, then we're wasting some potential, but we
+   if we reserve too little, then fewer people will opt to become servers.
+   How do we find the right balance?
+
+   One answer is that it doesn't have to be perfect: we can err on the
+   side of providing extra resources to servers, then we will achieve our
+   desired goal: when people complain about speed, we can tell them to
+   run a server, and they will in fact get better performance. In fact,
+   finding an optimum balance is especially hard because it's a moving
+   target: the better our incentive mechanism (and the lower the barrier
+   to setup), the more servers there will be.
+
+3.8. Anonymity attack: fast connections probably come from good servers.
+
+
+3.9. How do we allocate bandwidth over the course of a second?
+
+
+
 4. Sample designs.
 
 4.1. Two classes of service for circuits.
@@ -220,7 +243,7 @@
    we know that we can get away with poor performance for people that
    aren't listed in the directory.
 
-5. Types of attacks.
+5. Recommendations and next steps.
+
 
-5.1. Anonymity attacks: