[Blocks-development] Preventing duplicate file uploads, and feature recap

[Michael S. Jr. <m...@ms...>]

Here I go, resurrecting a dead list and finding out who is still alive out
there.  Remember Blocks?  It's still one-of-a-kind, still has all the
disruptive-technology potential, yet is still pretty much useless because of
all the convenience tradeoffs made to enhance security.  I'm interested in
making some of those tradeoffs optional.

Suppose two people have the same copy of a file they want to share.  Without
collaborating, they both join a network and both share the file.  The same
file data exists on the network with two different header blocks now, and
encrypted in two different ways.  Someone could download part of one file,
and the source would disconnect;  they would be unable to resume the file
from the other source, because as far as the system is concerned, it's a
different file altogether.

Suppose we tried to prevent that redundancy.  When a node tries to share a
second copy of an existing file, for which there already exists a file
advert, the node should try to download just the header block from that
existing copy of the file on the network.  If the file appears to be
identical to the file this node is trying to share, the node should change
how it caches its own copy of the file to match.  Now the existing file
header blocks and file adverts on the network also refer to this file.

What are the security implications of this?  Doesn't an attacker need to
reverse RIPEMD160 to forge an impossible file header block?  And if an
attacker publishes a nonexistent file header block and file advert, which
eventually does point to a real file, won't the attacker have merely helped
spread the new file?

Or if the attacker is allowed to *choose* the on-disk encryption key used
when he publishes his 'cooked' header block, will the attacker be able to
then prove/disprove that someone was sharing a certain file by seizing the
hard disk and looking for files encrypted with those keys?

----------

Many months ago, I asked for some of Peter Gunn's time, and he helped me
figure out FLTK, and walked me through some of the Blocks source.  I haven't
done *anything* with that information yet.  Tonight I plan on printing out
the Blocks source, to study it in my free time elsewhere.

Maybe then I can add a few missing features to Blocks and make it useful for
the masses.

My ideal feature list:
1)  add another layer of indirection to the on-disk block cache, so blocks
can exist in the original files instead of only in new encrypted disk
blocks.  This is a *major* killer, especially for movie downloads.  Make the
disk cache recognize and not expire the user's own manual uploads.
2)  make the 'download' function smarter, so it doesn't merely try to save
one file stream, but intelligently chooses file streams and creates the
destination file from many possible sources.
3)  add node identity security -- if a node directly connects to me, I want
to be able to verify whether or not it's a known trusted friend.  I might
want to only publish my own file adverts to known trusted friend nodes.
4)  Rate-limit the advert traffic.  Perhaps give 'advert-republication
queue' priority to adverts from known trusted friend nodes.
5)  GUI the hell out of it.

What do you guys think?  Would you start using Blocks again if feature 1 was
added, and you didn't have to devote copious amounts of disk space to
running a Blocks node?

Does disruptive filesharing technology interest the people still in this
list any more?

(I feel somewhat responsible for killing Blocks -- I kept going on and on
with my web-of-trust drivel.  I'm sorry, guys.)

--Spence