You are absolutely right about each and every one of these problems. However they are all the result of trying to force a scarcity biased economic model into a surplus biased network. A capitalistic model simply cannot work in this kind of distributed network. These problems can, and have been solved. Look at GNUnet. They have a LOT of papers describing EXACTLY how to do this. (and it works.) The idea is to use the economic model to determine the importance of returning any given request, or keeping any given file. This totally prevents DoS attacks on the network! What GNUnet does NOT do, is link it to any real world currency. So, you can exchange bandwidth for storage space, or storage space for getting your requests faster, but you cannot get real money out. The only way you could do that would be to become a public provider. IE: you run a public gateway node, and allow people to make requests and store data on the network using your higher priority for a fee. This is perfectly viable. Everyone PLEASE read the GNUnet docs before you start thinking of other ways to do this. > It seems Zooko's linking in of the Mnet routing/NGrouting message > happened at just the right time for me to catch this particular thread. > > 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 _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
