June 28, 2004
P2P's Tragedy of the Commons
Nightblade , a coder on p2p netrworks, wrote about the "tragedy of the commons" and how it tended to destroy systems. His words were too dangerous, as now the site is down. I've scraped the google cache, below .
Tragedy of the Commons is something we've all known about . I recall Bob H going on about it all the time. The solution is simple - property where there is scarcity. Unfortunately, property requires rights allocation, and payments, and methods of exchange.
Now, we've built all these things, but those building the p2p systems have not. Instead of going that distance - admittedly way beyond the expectation - comments in reply to his problem description (unpreserved) have stressed that there is a social element to this and if only the right social engineering approach can be found, it will all work. Which of course will not work, but it's a timely reminder of the sort of soft social thnking that has spread from the legacy of GPL.
Then, in our world, we've built the superlative rights allocation mechanisms. We've created strong payment systems (the field is littered with these), and we've done the exchange mechanisms. I've seen these things in operation, and when they are humming, the world moves dangerously quicker. Yet our application side has never carried it far enough.
So we have two worlds. One world knows how to build p2p. The other world knows how to solve the resource allocation problem. The question is, when do the worlds start colliding?
This was the central message of FC7 : Don't underestimate the complexity of the words. It is a multidisciplinary problem, which means there is a huge need to reach across to the other disciplines (I identified 7 core areas, and that's a lot to deal with. In brief, p2p chat would be a layer 7 application, and the above rights, payments, exchange are all layers 1 through 6.)
But FC7 was widely ignored, and in my discussions on many (other) issues, I've come to the conclusion that we as a species don't like multidisciplinary concepts. We want the whole solution to live in our space of expertise. We get all woolly and nervous when we're asked to dwell into unfamiliar territory, as seen by the desire to cast the tragedy of the commons into the familiar "social" context of the GPL crowd.
Our Internet Commons of Ideas and Potential Applications seems hardly in danger of over-grazing. More, we have a group of deaf dumb and blind developers sitting at the edge of the commons, occasionally falling over dead from starvation, while in the middle there is good grazing.
 Nightblade - dead link:
 Google cache
 Tragedy of the commons
 Financial Cryptography in 7 layers
Why P2P Networks Fail
Submitted by Nightblade on May 16, 2004 - 19:35.
Posted by iang at June 28, 2004 05:11 AM
This is something I have been thinking about for a long time. I believe it is one the main reasons P2P networks fail. (Another related theory is called the "prisoner's dilemma")
Here is an example from my own experiences:
A long time ago, I had a freesite on Freenet. Initially I was able to insert the site with no difficulty. However, as the network conditions grew worse over the weeks and months I found it more and more difficult to insert new editions of my site.
When I had inserted the first editions of my site, I used HTL values like 10 to 13 and only inserted the site once. I figured that would be enough to make it so people could see it, and they could. However as the network degraded I had to increase my HTL value to the maximum of 25, and perform multiple inserts over several hours before my site became viewable to other Freenet users. Part of this was prompted by Freenet coding bugs, but I think part of it was also caused by "overcrowding" - too much data was being inserted, causing sites to be lost too quickly as Freenet became more popular.
At the same time, I imagine other freesite authors were doing the exact same thing as I was, increasing their HTL and doing multiple inserts, possibly from multiple locations. While in the short term this solved the problem, it eventually turned into an "arms race." I remember just before I gave up on Freenet I was spending the entire day - 12 hours or more - continually ramming my site into the network with FIW, hoping it would work!
In addition to this madness there was Frost, which was a very heavy user (some would say abuser) of Freenet network resources. The end result was that the "commons" of Freenet - bandwidth and data stores, were overused and became nonfunctional.
Lest someone say that such problems in Freenet were caused by Freenet itself (i.e. bugs) rather than commons-overuse, let me give another example.
Take for instance Gnutella. At one time I shared about half my hard drive on Gnutella, but over the months and years I used Gnutella I got pissed off at all the "freeloaders" (people who download but don't share much), and I started reducing the number of files I shared. Other Gnutella users have done the same thing as I did. Now when I go on to Gnutella (or any other popular file sharing network) I find it very difficult to find anyone sharing files. Nobody shares anymore, they just leech. This is because the "commons" - bandwidth - was "overgrazed" by a few people, and those who were sharing stopped and began to leech instead, thus destroying the commons of Gnutella.
I also see this same problem potentially occuring in I2P.
At the moment, everyone is friendly and does not overuse the commons (bandwidth), but what will happen when I2P becomes more popular? Those without such altruistic behaviour as ourselves will begin wasting valuable I2P bandwidth.
Define "waste", you say? Suppose I develop a filesharing application which runs on I2P. People use my application to pirate the latest software, for example, Microsoft Office. Suddenly I2P becomes painfully slow. What do we do? We do not know which tunnels carry pirated software, because they are encrypted and anonymous. We can only sit and hope for the software pirates to become bored and go somewhere else.
Perhaps you do not find software piracy a wasteful activity.... then instead consider a government agency which creates multiple I2P routers and sends millions of gigabytes of garbage data across the network (WAV files of white noise, for example). That would have the same effect as the pirates would.
What is the solution to the "Tragedy of the Commons Attack?" This is what I have been thinking about, and so far I have come up with some solutions - private members-only networks in the style of WASTE seem to be the most promising.
What do you think?
I believe that humans need to simplify the complexity of the world. Complexity is a huge problem as it hinders straightforward decision making and instead stalls decisions. It is the one thing that makes projects succeed or fail: if the project manager is capable of "riding the wave", understanding the complexities and doing the correct abstractions, ultimately leading to correct decisions. IMNSHO, "Interdisciplinary" is just another word for complexity in this case.
If the 2 worlds collided, would the absolute size of the payments be considered micro payments? Or, in other words is the very low absolute level of e-gold's income from micro payments a result of there not being a major application for micro payments? After all, the DMC (digital metal currency) and the P2P scenes are still in their infancy.
I think DMC take off has to wait for the generational bull market in gold and silver tobe over with, plus a couple of years for gold's temporarily increase purchasing power (due to the bull market) to get back to normal after the top of the bull.
During the '70s bull gold went from $35 to $850, but its purchasing power using the PPI went up 400%. Those are "about" numbers. Good enough for illustration.
Only then will the DMC's 1.) unit of measure/account and 2.) medium of exchange elements/characteristics start to work well (when they stabilize). Of course their 3.) store of value element/characteristic is shining already, which is partly how gold and silver work and should work.
My guess is we're looking at 8-10 years. The last year or two of the bull will probably do wonders for new DMC users. Masses entering a bull near the top is normal human behavior.
After the bull, maybe, realizing a huge mass (hopefully) of DMC users existing out there, the P2P people will get interested in crossing over (getting more capitalistic). Maybe particularly after a scary economic downturn (depression). The need for survival can do wonders some times.
Currently there are still a huge amount of people who are waaaaaay too economically complacent, which could be why the tragedy of the commons idea is still being ignored by too many. We'll see.
I was directed here, and I'm glad you found my little essay interesting.
I have thought about this a lot, and of possible solutions using payments (either virtual currency created specifically for the p2p network, or real currency like e-gold or paypal).
There are some problems though, because if you have a virtual currency, there has to be some source for it, and that source becomes a central point of failure, which something we'd like to avoid in pure P2P. Specifically, I think I'd have to have some sort of "bank" which acts as a broker for the P2P transaction.
With the real currency system, you would have problems because people's identities could possibly be revealed. I am familiar with stuff like Yodel Bank but I haven't had time to try it out yet. I suppose it depends on what level of anonymity you need...
Well, I'm going to read your FC7 paper before commenting further. Maybe some of these problems have already been solved.
The issue of the central point of failure is not limited to p2p. It's a core part of the evolving digital currency sphere. It gets addressed in several, evolving ways:
Firstly, there are multiple issuers. That is, multiples of the gold issuers, and multiples of the dollar issuers. Secondly, a network of exchange operators springs up to conduct cambios from one to the other. These are generally small, independent, mom&pop shops. Their life is defined by one transaction, and they come and go. (Contrast: your broker comment.)
Thirdly, the manual cambios move to automatic cambios. This requires some finesse and coding, but if you know what you are doing, it can be done. There are about 2 in current operation between the various gold currencies.
Fourthly, and finally, there has to be some convergence on a common directed payment mechanism. XML-X is the example that I and some mates put together, but it is too early to say if this will be adopted. (But this has to happen, elsewise, programmers like yourself will find your choice of coding will also dictate your choice of single point of failure.)
Once all that is in place, you will have a currency system that exhibits no central point of failure. (There are other ways of doing this, but I'll leave those for now.)
W.r.t. anonymity in money - there is a lot of misinformation about what money is, and this is one of them. The primary characteristic of money is that it is safe, and this comes before anonymity. If you can't tell if it is safe, it matters nix whether it is anonymous or untraceable.
(Oh, also, bear in mind, there is a huge difference between payment systems, and banks. The two are not the same, one moves money around, and the other borrows and lends. The fact that one might be owned by the other, etc, v.v., is something that has to disentangled by the architect.)
Keep up the happy distributed fight!
I think you may be thinking that micropayments or what you labelled as DMC are different to other payments. They are not. There is "payments" and in that you can arbitrarily draw a line between different sizes. But they are all payments.
The notion that p2p people want micropayments and not (macro-?) payments is just a non-starter. People want payments. What they really want is trades. But they'll settle for payments and then engineer the trades themselves if they have to.
Or the notion that routers that feed of each other are happy with router-feed sized payments but not with others is also a totally bankrupt way of starting an analysis. You could even offer this sort of service, a router-bite payment, and I guaruntee you that the routers will reject them, even though you get their size spot on. That's because they want payments, not micro payments.
It's like any other business. Consider Tyres. Or even Tires. Companies don't make microtyres. They make Tyres. They might end up in a successful sized segment, but any time the action starts any where else, they'll move in real quick.
Interesting article Ian. I think it might help the debate along to consider what's been happening in virtual spaces where there are no commons (eg, Everquest). As economists would have correctly predicted, because non-existent places like the world of Everqeust have secure (within the limited bounds of passwords and other such sort-of-security) property rights and a stable means of exchange (eg, platinum pieces), they experience economic growth greater than real places with no property rights (eg, much of the developing world)!
Do we want the P2P world to be more like Norrath or more like Zimbabwe?
It so happens that the I2P network has a capability called certificates, which make it possible to have payments of various sorts attached to an address ('Destination' in I2P lingo). I am going to have to find out how I can incorporate this into an I2P application I am working on.
Also, interesting comments on micropayments versus macropayments. Personally I just think micropayments would be an annoyance, for both the sender and recipient. However, what if one large macropayment was made (say $100 USD) to a P2P payment service (which could be semi-anonymous), which in turn transparently handled micropayments on the user's behalf (buying/selling network resources). There would probably have to be some kind of reasonable minimum though, like $1, otherwise it wouldn't be worth the trouble.
I think you can generate hashcash tokens for the I2P network, these are not payments but "expensive hashes" which slows people down in acquiring the nice names. This is from memory. Hashcash is a resource contention idea from Adam Back that tries to stop automated abuse of free resource. It's a nice idea, however it is dominated in most practical senses by payments.
For buying resources - the automated dishing out of payments for small amounts isn't a particularly easy thing to implement. Many have tried, I've never seen any successes. To cut a long story short, marketing theory says that instead of paying per item for small cost resources, you purchase a subscription that lasts for a while. So, what will happen is that all these resources will take larger payments and give you hundreds of items or a year's worth of access.
Dave! Nice examples. Everquest - its property rights and payments are guarunteed by the over-arching power of the company and its game. Likewise, economists like deSoto (who I'm embarrassed to say I haven't read) have predicted and explained the Zimbabwe situation. The big gotcha in all this is that property rights (and payments are just an extension of that) are "provided by the government." How then to put property rights onto the Internet in large form is the question - without any government, who will surely not understand and migrate it across to some agenda item or other.
Our Ricardian Contract is one form. But we haven't really answered how to get the knowledge and infrastructure into wide enough distribution such that people can issue themselves in a p2p context as yet. The result is easy for the users, but issuing these instruments remains costly.
I don't like hashcash. IMO, it annoys users by wasting their CPU power, and it does little to cut down on resource abuse by professional abusers. Sure, hashcash may slow down a teenage script kiddie, but I don't think it will deter a professional attacker. For example, the NSA probably has the computing power to generate more hashcash than every civilian computer in a small European country does. Hashcash also suffers from inflation as computing power increases.
For those who don't believe the NSA would do such a thing, a similar effect could be created by designing an internet worm that performs distributed hashcash generation. (Just as internet worms are created to mail spam today.)
However, hashcash is just one of the certificates I2P could use. It should be possible to have other kinds of payments.