[tahoe-dev] Resurrecting Mojo Nation

James A. Donald jamesd at echeque.com
Sun Jun 10 02:26:14 PDT 2012


On 2012-06-10 2:07 PM, Jack Byer wrote:
> This isn't the first time a combination of Bitcoin and tahoe-lafs has
> been suggested but I'd like to ask a different question than just
> whether or not is makes sense to use bitcoins to pay people for
> storage. Is it practical to go back to the original goal of MN instead
> of a limited subset if the reasons for the project's failure are
> addressed? From what I can tell the pricing mechanism of MN was broken
> because it didn't really have a market. A market needs independent
> decision-making agents bidding against each other to resolve
> conflicting goals and MN didn't have that. It's not realistic to
> expect users to sit in front of a screen all day and daytrade Mojo in
> order to achieve price discovery.

Mojo nation had an automatic auction scheme:  When acting as a server your 
computer serviced requests starting with those offering the best price, 
down to the worst, thus when operating as a server, automatic price 
discovery.

When acting as a client the client should have automatically adjusted its 
offers in accordance with its user's performance goals and price limits, 
trying automatically to pay the lowest price consistent with adequate 
service, trying to discover market clearing prices with minimal human 
intervention and make that information available to the user.  I don't 
think it did.  So as a server, there was automatic price discovery, as a 
client, there was, to the best of my knowledge, no useful automatic price 
discovery.  For micropayments, where your computer performs lots of 
transactions on your behalf without consulting you, this was an 
unacceptable flaw.

I have never seen a post mortem from the Mojo Nation developers.  Would  
like to see one.  Perhaps one exists, and I just missed it.

Seems to me that Tahoe fails because it retreated from the goals of Mojo  
Nation - as Mojo Nation itself did.

To achieve reliability, you really want a large number of servers, for a  
large number of servers you need a large community, preferably the entire 
world as one community, but if you have large community, tahoe gives you 
the tragedy of the commons.  Tahoe relies on social enforcement of good 
behavior. A community large enough to produce benefits from shared and 
distributed storage is large enough that the cost of informal social 
enforcement of good behavior is excessive - and bad social behavior results 
in unreliable storage.

Also, tahoe abandons EGTP.  We need a replacement for TCP that provides  
end to end encryption, protocol negotiation, and NAT tunneling.  TCP is an 
unworkable protocol in a large, untrusting, and untrustworthy society.  
EGTP was such a replacement, or was intended to be such a replacement.

I would say that the main result of the Tahoe experiment is that you  
really have to do what Mojo Nation attempted to do, and that the subset  
has problems.

Bittorrent was a successful descendent of Mojo Nation, but because storage 
is not rewarded, torrents go unseeded.  Need to reward both storage and 
bandwidth.

Mojo Nation done right would be bittorrent with the capability to support 
both mutable and immutable files (a torrent is an immutable file), with an 
incentive to seed, and with the capability to support an enormous number of 
inactive seeds without overhead costs.

We would like the capability to support mutable files, as tahoe does, so  
that we can have lists of immutable files, as tahoe does.  Such a mutable 
list would be the equivalent of the pirate bay.
_______________________________________________
tahoe-dev mailing list
tahoe-dev at tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE





More information about the cypherpunks-legacy mailing list