bluesky AT lists.ibiblio.org
Subject: Global-Scale Distributed Storage Systems
List archive
- From: hal AT finney.org
- To: bluesky AT franklin.oit.unc.edu
- Subject: Re: Freenet's hashing algorithm
- Date: Thu, 15 Feb 2001 22:32:11 -0800
graydon AT venge.net writes:
> this strikes me as a conflation of matters, with serious drawbacks.
>
> * lack of friendly names
> * inability to change data without renaming/moving it
> * no actual improvement in security. the fact that the data satisfies
> the hash is vaccuous; any data will satisfy a CHK pointing to it,
> regardless of who put it there or how "true" it is. what you care about
> is that the data you retrieved is the data some party intended you to
> receive, and if you read a CHK off a tee shirt there is no reason to
> believe this CHK is any more trustworthy than a press release from the
> government of EvilLand.
A content hash should be thought of as a shorthand or abbreviation for
the document it represents. It is an unforgeable short-name, and in
principle an unforgeable address. Whether via Freenet or via some more
conventional lookup system, you can have a system to go from hash to data.
There are good uses for such documents. Not all documents need to be
updated; sometimes you want documents which *can't* be updated: legal
agreements, for example. Any time you want to make sure that someone
sees a particular revisions of a document you can give them the content
hash as a pointer. Archival or historical data can be well served with
such hashes.
Even when you need updates, content hash addressing can serve as a layer
over which you can build an update/revision system, as Freenet is doing.
Hal
-
Freenet's hashing algorithm,
hal, 02/15/2001
- <Possible follow-up(s)>
- Re: Freenet's hashing algorithm, graydon, 02/15/2001
- Re: Freenet's hashing algorithm, hal, 02/16/2001
- Re: Freenet's hashing algorithm, graydon, 02/16/2001
- Re: Freenet's hashing algorithm, hal, 02/16/2001
Archive powered by MHonArc 2.6.24.