[tahoe-dev] Resurrecting Mojo Nation
James A. Donald
jamesd at echeque.com
Sun Jun 10 09:26:14 UTC 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.
More information about the tahoe-dev
mailing list