Drew Bradford wrote:
[...]
>I had in mind something that wouldn't need to start off with a way to convert to hard currency. Rather than being able to >be converted into hard currency, it would have some sort of digital backing, ie. bandwidth, hard drive space, etc.
>
>The currency would then be self-regulating. It wouldn't be pegged to any real-world currency, but rather its value would >be set by supply vs. demand.
Yes, and you could call it Mojo...
That was what we did with Mojo Nation, and while it works up to a point you have no idea of the difficulties involved here. Let me highlight a few for you to think about (most of these also apply to people dreaming of attaching e-gold et al. to p2p networks as well):
1) What is a KB of storage, bandwidth, or a unit of CPU power actually worth? You can't just cost out what it would take to buy the equivalent because your users have already paid the capital investment required to provide the goods and there is almost no ongoing cost to operate the resource providing node a user has no reason not to drop the price to an infinitesimal fraction above zero. In fact, if there are other benefits to the node--like reputation/karma or if there is a non-zero switching cost for customers--then there is no incentive for them not to drop the price all the way to zero to gain some customer lock-in. Since unused bandwidth, for example, cannot be stored or saved over time it is a use it or lose it situation. This leads to a race to the bottom on pricing, followed by a wild rise when nodes drop out because there is nothing to be gained by participating when the cost drops to zero. Computation resources are what economists call a "zero cost good", which is going to work against your efforts. Users expect stable prices, but the reality of computational resources makes this impossible to provide. Users are also completely oblivious to how worthless their edge resources actually are and will end up getting angry when they aren't making as much "money" as they think they should.
2) Once you add economics into the mix people start thinking that they are sitting at a trading desk on Wall St. and forget about why they wanted to run a node in the first place. They will try to game the system, if for no other reason that to have "the most" of a currency that they are, by their own actions, making worthless. Regular users get screwed while obsessive-compulsive hackers with too much time on their hands try to play pricing games. Given the fact that networks which aim for anonymity have a very low entry cost and very low identity threshold, what it to prevent me from creating 1000 "virtual" nodes/agents, having them run up large debts and then disappearing?
3) Assuming you can figure out the structural and social problems in #1 and #2, you have to build a payment system that is both lightweight and secure. Consider the number of transactions that might be involved here. Will pricing be fixed or dynamic, if dynamic how much overhead is involved in to agents coming to agreement on the cost to process a transaction? Will each agent set its own price for the good, or will a centralized trading desk try to set some price ranges for resources? Anonymity prefers the first choice, but it makes the network so vulnerable to attacks on the pricing system as to make it trivial to destroy the value of the currency because there is no one who can see the overall flow of the payments or prices, so no one knows that a few people are out there screwing everyone else until it is too late. You can do a centralized "bank" which still maintains strong anonymity features (see most of Chaum's work and in particular think about combining Chaum and Evariste's anonymous credentials with Raph Levien's flow-restricted networks) but this is going to take a ton of work by some very smart coders to even get off the ground and a lot more work for it to actually be secure and stable.
4) Supply and demand is something that fluctuates wildly on computer networks. There are certain times that the network will be overloaded with excess capacity and other times that it will be starved for resources (you should check out some of the good work that came out of the MIT Agents group back in the early 90s on this subject, and definitely find the "Price wars and niche discovery in an information economy" paper.) Remember that it is easy for people to add or remove resources from the network just by turning on or turning off agents, and there is no cost to the user for this action (does Enron and California's electricity market ring a bell here? :)
5) How do you handle what bankers call "settlement"? When party A owes 10 credits to party B and party B owes 10 credits to part C you would assume that you can just do a A->B->C transaction, or even better have A send the payment directly to C. Now what happens if the transaction fails midway through the process? What if a packet gets lost and one party thinks the transaction has completed while the other party claims it never received payment. What if one party is not telling the truth when this claim is made? What if A and C decide to screw B by actually performing the settlement but claiming to B that they were unable to make a connection?
6) How do you handle failed transactions and refunds? If this ever gets tied to a real currency then people will suddenly start going ballistic if their 2 cent transaction fails or gets lost. What about double-spending? How much will it cost per transaction to support the mechanisms necessary to handle these situations? Look at how draconian PayPal has to be about transactions, and they are actually the ones performing the settlement.
7) One factor that a network like Freenet in particular would need to worry about is that an agency or group that has a large amount of resources available (certain three-letter agencies, four-letter trade groups, and national governments come to mind) will throw resources in to the network to try to attack the infrastructure that the economic system is regulating. At the present it is hard for me to attack Freenet by injecting nodes and putting myself into key choke points in the network so that I can perform traffic analysis on the network, but if economics enter the picture I can essentially pay money to map out the network and to insert myself wherever I want (I can afford to keep my prices at zero because I am not playing the game to make "money" but I am instead aiming to direct all traffic through nodes I control.) Adding money changes the incentives for some users of the network, but it is possible for an attacker to use that against you.
Adding payment systems to P2P sounds cool, but it is a bitch to pull off and unless there is a _real_ need for it you are going to just be inviting headaches and attracting the wrong sort of attention. Trust me on this. Doug Barnes, my Mojo Nation co-founder, knows Neal Stephenson pretty well (read the acknowledgements section of Cryptonomicon) and we are both long time cypherpunks who had been working on ways to make a "data haven" work since we met in the early 90s; even after all of that research and thinking and talking with people who had good ideas we made lots of mistakes. Then, after putting together an alpha test system around the same time as Freenet appeared, we (I) made the mistake of looking at Napster at the wrong moment in time (very early on, when only a few people had access to MP3 encoders so ripped songs and always-on connections were the valuable commodity and there was a significant leecher to uploader ratio) and based our decisions on that. We managed to turn things in the right direction after getting a "I am in town for a conference and we need to chat" lecture from Dr. Andrew Odlyzko (whose papers you _must_ read before attempting any of this...), but in the long run it was more bother than it was ever worth.
Your intentions are good, but I really want to warn you that you are wandering into a rather painful minefield here... Unless you are solving a problem that will otherwise destroy the network within the immediate future I would suggest that your efforts could probably be better spent solving other Freenet problems.
Jim McCoy
_______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
