[or-cvs] add another related issue to think about

arma at seul.org arma at seul.org
Wed Feb 1 06:45:18 UTC 2006


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

Modified Files:
	incentives.txt 
Log Message:
add another related issue to think about


Index: incentives.txt
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/incentives.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -d -r1.1 -r1.2
--- incentives.txt	31 Jan 2006 09:10:13 -0000	1.1
+++ incentives.txt	1 Feb 2006 06:45:15 -0000	1.2
@@ -53,7 +53,20 @@
 
 3. Related issues we need to keep in mind.
 
-3.1. The network effect: how many nodes will you interact with?
+3.1. Relay and exit needs to be easy and usable.
+
+   Implicit in all of the above designs is the need to make it easy to
+   run a Tor server out of the box. We need to make it stable on all
+   common platforms (including XP), it needs to detect its available
+   bandwidth and not overreach that, and it needs to help the operator
+   through opening up ports on his firewall. Then we need a slick GUI
+   that lets people click a button or two rather than editing text files.
+
+   Once we've done all this, we'll need to face the big question: is
+   most of the barrier to growth caused by the unusability of the current
+   software? If so, are the rest of these incentive schemes superfluous?
+
+3.2. The network effect: how many nodes will you interact with?
 
    One of the concerns with pairwise reputation systems is that as the
    network gets thousands of servers, the chance that you're going to
@@ -63,7 +76,7 @@
    means we need to be aware that this is a limitation, and plan in the
    background for what step to take next.
 
-3.2. Guard nodes
+3.3. Guard nodes
 
    As of Tor 0.1.1.11, Tor users pick from a small set of semi-permanent
    "guard nodes" for their first hop of each circuit. This seems to have
@@ -80,13 +93,15 @@
    also through indirect interaction (middle of the circuit). That way
    you can never be sure when your guards are measuring you.
 
-3.3. Restricted topology: benefits and roadmap.
+3.4. Restricted topology: benefits and roadmap.
 
    As the Tor network continues to grow, we will make design changes
    to the network topology so that each node does not need to maintain
    connections to an unbounded number of other nodes.
 
-3.4. Profit-maximizing vs. Altruism.
+   A special case here is the social network.
+
+3.5. Profit-maximizing vs. Altruism.
 
    There are some interesting game theory questions here.
 
@@ -103,8 +118,6 @@
    for an incentive scheme so effective that it produces thousands of
    new servers.
 
-3.5. Tor design changes that need to happen.
-
 4. Sample designs.
 
 4.1. Two classes of service for circuits.



More information about the tor-commits mailing list