From: Kent Crispin <kent@songbird.com>
Date: Mon, 19 Jan 1998 04:09:31 +0800
To: Cypherpunks Distributed Remailer <eternity@internexus.net
Subject: Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)
In-Reply-To: <tw790sdllr5.fsf@the-great-machine.mit.edu>
Message-ID: <19980118120234.40255@songbird.com>
MIME-Version: 1.0
Content-Type: text/plain



On Sun, Jan 18, 1998 at 12:45:02PM -0500, Ryan Lackey wrote:
[...]
> 
> Data disappears from Eternity once no one cares enough about it to pay to
> have it stored.  That could mean someone doesn't pay in advance for the data,
> or no one is willing to invest disk space in the hope that it will in
> the future be downloaded.
> 
> Providing eternity service costs money.  Anything which lets users circumvent
> this opens up the potential for denial of service through consumption of
> resources attacks.  Even if billing is fundamental, you still have the
> potential for the NSA to spend $100m to buy all the eternity space available
> at any point.  This is why you also need market mechanisms -- if the NSA
> is willing to pay a premium for eternity service just to keep it out of
> the hands of the populace, then running eternity servers is a great 
> investment, so capacity will increase until the NSA can no longer afford
> to buy all of it.
> 
> A difficult part of designing a working Eternity service is to keep people
> from "stealing service", in terms of consumption of resources, during
> set up, indexing, etc.  Basically, you need to make sure that to the 
> greatest extent possible, anything which is a potentially scarce resource
> is sold, not given away.

There are alternative ways of paying for the service that do not in
any way depend on ecash, and after thinking about it a bit, they seem
more robust, as well. 

The basic idea is as follows:  The fundamental eternity service is 
free to readers, and is financed entirely by writers.  The writers 
supply the disk space, the network bandwidth, and possibly pay for 
the software to support all this.

In a little more detail: you have say 1 megabyte of data that you
would like to be stored in the Eternity Service.  The overhead of
storage in eternity is a factor of two, and you would like 10 times
redundancy.  So you contact the Eternity Service Software provider, and 
get the software.  You then configure the software to supply 20 
megabytes of your disk space to the system.  This allows you to 
supply 1 meg of your own data.

The 20 megs will of course not store *your* data -- it will store
other eternity data.  The service takes your data and spreads it
across 10 other sites, whose locations are unknown and unknowable to
you.  In return, you are storing eternity data for other users.  If
your disk space becomes unavailable your file disappears from the
service.  (Of course, someone else could pick it up and store it, if
it was valuable information.)

This is a self-financing model.  Every writer to the eternity service
pays for their own bandwidth and disk space.  The eternity service
provider is financed by maintaining the software that all the writers
use -- client/server software will have to run on many different
platforms, some protocols may be better than others, and it might be 
worth buying your eternity software from a high-reputation 
("trustworthy") provider.

Note that this doesn't mean that data suppliers can't be paid for
providing data -- but that is a completely separable problem that can
have many different solutions.

I believe this approach does solve the financing part.  But it does
make the rest a *very* complicated problem -- you have a dynamic,
self-configuring network of data sources and sinks, with all the
configuration data encrypted along with the data.  Ideally, of course,
the data would be migrating constantly. 

Retrieval would probably be very slow -- basically email speeds, or 
worse.  In fact, perhaps the data would be retrieved by having the 
eternity service use the remailer network to send it...

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html