1998-01-12 - Re: (eternity) mailing list and activity

Header Data

From: Ryan Lackey <rdl@mit.edu>
To: Adam Back <aba@dcs.ex.ac.uk>
Message Hash: f02d6fd155d3db0a811c954f7a890c4f3ed01ac1a274e0e8cffd6efded7f2e80
Message ID: <199801120432.XAA12666@the-great-machine.mit.edu>
Reply To: <199801112144.VAA00285@server.eternity.org>
UTC Datetime: 1998-01-12 04:36:43 UTC
Raw Date: Mon, 12 Jan 1998 12:36:43 +0800

Raw message

From: Ryan Lackey <rdl@mit.edu>
Date: Mon, 12 Jan 1998 12:36:43 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: (eternity) mailing list and activity
In-Reply-To: <199801112144.VAA00285@server.eternity.org>
Message-ID: <199801120432.XAA12666@the-great-machine.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----


Adam Back writes:

> Firstly note that there are 3 (three) systems going by the name of
> eternity service at present.  

I've heard that there are perhaps as many as two more which are vaguely
non-public, as well.

> And there is Ryan Lackey's Eternity DDS (where DDS stands for I
> presume Distributed Data Store?).  I am not sure of the details of his
> design beyond that he is building a market for CPU and disk space, and
> building on top of a an existing database to create a distributed data
> base accessible as a virtual web space (amongst other `views').  He
> gave this URL in his post earlier today:
> 
> 	http://sof.mit.edu/eternity/

I'm only using an existing database for reasons of expediency in prototyping.
The actual production system will include no commercial code.  Oracle is
a bloated pig for this kind of thing, too.  One of the 'views' for the
data will be a virtual database.

> [description of how to commit data in Adam Back's Eternity Service implementation elided]

My current design will require some kind of interface between users and 
eternityspace
in order to commit data.  Since the pricing/specification/etc. system will be
rather sophisticated, I'm also working on a simulation tool to assist users in
committing data.  However, it will be possible in my ideal implementation for 
a user
to fill out a form with duration of storage required, 
bandwidth/accessibility/uptime
requirements, a pro-rated schedule for nonperformance, amount of space needed, 
amount
of computation needed, etc. and attach their object.  Then, there will be a 
market
based system which lets people bid on storing that data -- various indices of 
prices
will exist (although since it is multiaxis, they will have to be surfaces, 
with a large
amount of interpolation).  Someone will buy it, perhaps resell in a recursive
auction market, etc.  There will be a designated verifier which will make sure 
the
contract is met, using a variety of mechanisms designed to preserve anonymity 
and
prevent fraud, and enforce the contract.  Payment will be held in escrow, 
disbursed at
pre-specified intervals, again totally anonymously.

Since these contracts are negotiable, there should be a market in 
selling/trading/etc.
old Eternity contracts.  As the realities of storing data change, the market 
will take
this into account, and up or down value existing and new contracts.

Potentially, one could even use Eternity storage as a kind of currency.  The 
system would
seem to be purpose-built for money laundering, once it is big enough that
all money going into or out of the system is not monitorable (a threshold which
depends on the design of the system and payment scheme as well).


I think I'm going to take a break from my demo writing to work on some public 
documents.
Some parts of my current system are total mock-ups, others don't yet exist.  
My "two-way
anonymous e-cash implementation" is a chit file in /tmp on my machine (heh), 
and
putting data into the system requires serious frobbing.  And Oracle is 
handling most of
the coherency/etc. issues right now.
- -- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/		



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNLmcw6wefxtEUY69AQH+tgf8Ctsg6UJbGzDhzeXwNKYB6qI+afTnKWkw
sYgyRf/tKEual6yaXymiCBswUzfW39jdqkQ313DPlGQzovCq6AcsXQyhk5H93h+e
V5aI2belCUEUFxJ21WUj++ZtM5vSh0lcFAlz/w3ejuju7Il27uW8vDVfHjOBg65m
oO6F7Wi4Wp2V4B4720KieHLhs9Rg9YGNVsDZPSgfY5KFpcDylpEARW6ipCceBQu+
fLrT+or4T3KVSKR7hSPMxULw/FKarMAz+xpyBXFt8UQMEU0azBVhPU3Ui5VPUZ+o
mVMBiZKDFU4dvQCNygcGtebQ1JUFy3YKq48SuTYBr4FPyYNWMgGCSQ==
=oRpR
-----END PGP SIGNATURE-----






Thread