1998-01-20 - Re: (eternity) Eternity as a secure filesystem/backup medium

Header Data

From: Jonathan Wienke <JonWienk@ix.netcom.com>
To: <eternity@internexus.net
Message Hash: c28de5545bfc18d4027aae3bc5e5ab5425e171e6df4b597b93f293c57b8c29cb
Message ID: <3.0.3.32.19980118151314.006b7d88@popd.netcruiser>
Reply To: <tw790sdllr5.fsf@the-great-machine.mit.edu>
UTC Datetime: 1998-01-20 03:10:04 UTC
Raw Date: Tue, 20 Jan 1998 11:10:04 +0800

Raw message

From: Jonathan Wienke <JonWienk@ix.netcom.com>
Date: Tue, 20 Jan 1998 11:10:04 +0800
To: <eternity@internexus.net
Subject: Re: (eternity) Eternity as a secure filesystem/backup medium
In-Reply-To: <tw790sdllr5.fsf@the-great-machine.mit.edu>
Message-ID: <3.0.3.32.19980118151314.006b7d88@popd.netcruiser>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


At 01:04 PM 1/18/98 -0600, Jim Choate wrote:
>The point is that the system can *always* be spammed. You *don't* charge
the
>source of data a million dollars to put it on your server. It's gotta be
>source cheap or else it isn't worth their time to bother with it. If you
>*really* want to promote such servers what you need is a model that allows
>submitters free access *and* a share in the subscribers fees. Then
everyone
>wins.
>
>If the source has something they know is worth god awful sums of money
they
>aren't going to submit it to the data haven anyway, they'll set their own
>haven up and reap the benefits directly. There is an economic issue here
>that is at parity with the technical issues.

Here is a way for an individual to make money using the eternity service:

1:  Users are charged $/MB/month to store data in the service.

2:  Users are charged $/MB for downloading data from the service.

3:  The source of a data item receives a portion of the download fees
collected for that item as an anonymous payment, or else the money could be
applied toward keeping the data on the service (the option of choice for
the really paranoid among us).


At 12:02 PM 1/18/98 -0800, Kent Crispin wrote:
>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.)

The location of the data should be determined by some sort of random
process, and it should move frequently.  Disallowing one to store one's own
data reduces the number possible locations for the data, and also requires
a mechanism for matching the source of the data to the owner of each node-
both of which are Really Bad Karma.

>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.

One could also construct a fee schedule where a higher rate would buy a
higher redundancy level for your data.

>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...

The eternity service should be its own remailer network--one that transfers
data as well as e-mail.  The nodes should have constant encrypted cover
traffic between them.

-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5

iQA/AwUBNMKMicJF0kXqpw3MEQJ/sACfQpkRqLflEPdmr4NpsP/8w7WEmvIAnjvv
LSkxnt7fdHwkCk37vMWf/q1A
=P6/D
-----END PGP SIGNATURE-----


Jonathan Wienke

PGP Key Fingerprints:
7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC

"If ye love wealth greater than liberty, the tranquility of servitude
greater than the animating contest for freedom, go home from us in peace.
We seek not your counsel, nor your arms. Crouch down and lick the hand that
feeds you. May your chains set lightly upon you; and may posterity forget
that ye were our countrymen."
-- Samuel Adams

"Stupidity is the one arena of of human achievement where most people
fulfill their potential."
-- Jonathan Wienke

Never sign a contract that contains the phrase "first-born child."

When the government fears the people there is liberty.
When the people fear the government there is tyranny.
Those who live by the sword get shot by those who don't. 

RSA export-o-matic:
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`






Thread