Financial Cryptography

In the brainstorm/study phase of ePointSystem development, we had a hard look at MojoNation, as our primary goal was -- and to some extent remains -- a workable community currency for p2p services.
As a reason of failure, we pinpointed hyperinflation. MN had no anti-inflation measures and in due course, mojo got inflated into oblivion.
It's interesting, that you don't even mention this financial aspect.

I would probably disagree with this point. The reason inflation occurred is that we swallowed too much "open market" BS and let users set their own prices for services. For core messaging protocols (e.g. our "Hello" message used to establish a connection) some clever users figured out that they could steal everyone else's credits by setting an outrageously high price for responding to this message. Responding to this problem required us to hand out more credits to existing users.

OTOH, there is a good case to be made that dynamic pricing is a losing proposition with boom and bust cycles in a network where most services are zero-cost (e.g. if I don't use my bandwidth now I can't save it up for later use.) Take a look at the problems encountered by the early deregulation of the electricity market as an example and then remove the high capitalizatoin costs for bringing new capacity online and you have an idea of how hard this would have been to actually accomplish.

In the later iterations of the tech the pricing was divided into two categories: respond to this request "whevener" (no cost to purchaser) and "do it now" (dynamic pricing.) The intention here was to keep a lid on the dynamic prices. Unfortunately we never really had a chance to test this bit out in the wild for very long.

I could probably have spent more time discussing the "financial" failures of the system, but I think that some of the issues are still being resolved, some lack any real data to back up conclusions, and the rest would have required another long posting that I don't really have time for...

Price control provably results in market failuers. Capping prices does not prevent inflation, just transforms it into shortages (been there, seen that -- again and again).
Inflation is always caused by the issuer. People putting high pricetags on certain services should have not been able to sell them at that price. The mojo hyperinflation was a textbook case of issuer failure, in our opinion. What you describe is perfectly consnistent with this assessment.

I think there is a big difference between macro theory and practice, and that which is seen in startup and evolving markets. Yes, capping prices and overissuance causes all sorts of problems, but when a market has not reached a full competitive status, normal competitive pressures won't be felt.

I'd say given all I've read that Mojo Nation never made it to the point where it exposed full competitive market processes. Somewhere someone said one of the problems was that very few people ever downloaded any content; in such a place, the market wasn't one of supply and demand, it was more one of download and hack the system.

So I'm not convinced about inflation and prices. Still, I wasn't there, which was why I was bothering these gentlemen to get it down on paper in the first place :)

Before sketching the design for ePoints, we sat down with Agnes in her apartment and analyzed the stories of as many failed on-line payment systems as we could, in order to avoid their mistakes. It took several all-day brainstorming sessions. Mojonation was one of these systems, and what information was accessible about it suggested that they got sucked into the vicious circle of self-perpetuating hyperinfation:
First, they allowed some unbacked currency into the market -- mojo was handed out without any service in exchange.
Then prices started crawling up, as those gouging the prices did not feel the pressure of diminishing demand.
Suddenly, precisely as described above by Jim, the operators found a system with an insatisfiable thirst for mojo, and they had to keep pumping mojo into it, just to keep it running. Classic case of a runaway hyperinflation, IMO.

I think, the lack of content was not the root cause of failure, but a consequence of mojo monetary policy. Offering valuable content for download should have been the only way of earning mojo.

Then I would suggest that you have taken the wrong lesson from MojoNation or have bought into some sort of vision about how what the world really needs is a p2p digital cash system... (I know that we did at one point.) Inflation really had nothing to do with the problem, and if that is the lesson you take away from our experience you might end up repeating our mistakes.

You might want to check out the essay written by Bryce Wilcox-O'Hearn (aka zooko), one of our key coders at the time, that you can find at http://zooko.com/zooko_stuff.html for more info on the structural & implementation problems we encountered and how this turned the micropayment system into a development distraction rather than a useful feature.

Eiither way, good luck.

Thanks for the link! And yes, I have bought into the vision that the world desperately needs a p2p cash system. Without one, e-commerce will remain a major PITA.

The thing that disappointed me about MN was that originally, Mojo was going to be worth something. There would be genuine value and scarcity associated with it. Then everything went wrong. Due to bugs in the system and some shady operators, people found ways to steal Mojo from other players. They were hacking their clients to exploit features of the protocol that didn't work well in an adversarial environment. So MN had to start giving Mojo away to its testers, and pretty soon you could get as much as you wanted.

The ironic thing is that the only reason people tried to steal and horde it was because they hoped it would someday be valuable. That never happened, in part because of the effects of their own actions.

I agree with Daniel that the lesson isn't that markets don't work or that financial mechanisms can't allocate scarce resources. Rather, the MN software was just too immature and buggy, and it had too many built-in assumptions and automatic responses that could be exploited by a savvy peer.

Related to this inflexibility, some desirable Mojo flows were restricted by the system. It distinguished between publishers, who provided disk space and bandwidth, and content creators. That's good. But sometimes content creators might want to pay publishers to get their content out there, and other times publishers might want to pay content creators for supplying valuable content. But the system didn't allow both directions of Mojo flow, it had a built in assumption about which one people would want to use (I don't even remember any more which one it was, but apparently the MN people never even thought of the other case).