blocks-development — Main mailing list for Blocks

[Blocks-development] V0.16 bug#2

[Blat F. <pet...@ho...>]

Doh! I just found another bug. I replaced the slow uploads
with painfully slow downloads :-) still shouldnt cause
things to crash tho. Patch will be out in a day or two,
or when I can find the crash bug.

ttfn

PG.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

[Blocks-development] V0.16 bug#1

[Blat F. <pet...@ho...>]

Well, I found the first bug in V0.16. Big files still
trample over small caches. However, this shouldnt cause
the program to crash.

I'll wait for more info on the crashing problems
before I release a patch.

Luke, Michael, what error did Windoze actually post
when it crashed? Was it an 'illegal instruction',
'cant access memory', or what?

ttfn

PG.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [Blocks-development] Duplicate Connections

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

Close.
209.180.104.202 is the official server running Linux.
209.180.104.204 is running three copies of Blocks, out of e:\test1,
e:\test2, and e:\test3.
When I got home from work, test3 had crashed.  I'm going to build a debug
copy of Blocks and see if I can get that to crash.  :)

--Michael Spencer
bl...@ms...

----- Original Message -----
From: "Blat Froop" <pet...@ho...>
To: <blo...@li...>
Sent: Tuesday, August 29, 2000 5:24 PM
Subject: Re: [Blocks-development] Duplicate Connections


> >From: "Erik Moeller" <mo...@sc...>
> >To: blo...@li...
> >Subject: [Blocks-development] Duplicate Connections
> >Date: Tue, 29 Aug 2000 20:45:31 +0200
> >
> >The BlockNet is getting bigger, probably because of the infoAnarchy
> >announcement. I noticed that I get duplicate connections to one
> >server (209.180.104.204, Michael's server), all on the same port &
> >the same direction (0).
>
> Thats because Michael is running more than one server, and he's
> behind a Linux box doing IP Masquerading :-)
>
> ttfn
>
> PG.
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] Duplicate Connections

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: [Blocks-development] Duplicate Connections
>Date: Tue, 29 Aug 2000 20:45:31 +0200
>
>The BlockNet is getting bigger, probably because of the infoAnarchy
>announcement. I noticed that I get duplicate connections to one
>server (209.180.104.204, Michael's server), all on the same port &
>the same direction (0).

Thats because Michael is running more than one server, and he's
behind a Linux box doing IP Masquerading :-)

ttfn

PG.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [Blocks-development] Duplicate Connections

[<lu...@et...>]

* Erik Moeller wrote:
> The BlockNet is getting bigger, probably because of the infoAnarchy 
> announcement. I noticed that I get duplicate connections to one 
> server (209.180.104.204, Michael's server), all on the same port & 
> the same direction (0).

I see the same thing.  3 connections to 209.180.104.204 port=7397 DIR=0

-Luke

[Blocks-development] Duplicate Connections

[Erik M. <mo...@sc...>]

The BlockNet is getting bigger, probably because of the infoAnarchy 
announcement. I noticed that I get duplicate connections to one 
server (209.180.104.204, Michael's server), all on the same port & 
the same direction (0).


-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

Re: [Blocks-development] Two crashes

[Erik M. <mo...@sc...>]

On 28 Aug 2000, at 18:11, lu...@et... wrote:

> I've had two crashes in the past hour or so, both when (I think)
> someone was attempting to download something from me.  Anyone else see
> this? I'm on Win2K.

No crashes here so far, but all other adverts seem to have 
disappeared even though my connections are still active. 

I'll idle on EFNet #blocks in the next few hours, if anyone wants to 
test ..

-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

[Blocks-development] Two crashes

[<lu...@et...>]

I've had two crashes in the past hour or so, both when (I think) someone
was attempting to download something from me.  Anyone else see this?
I'm on Win2K.

Headed home to try again.

-Luke

Re: [Blocks-development] 85 char filename limit

[<lu...@et...>]

> I'll increase it in V0.17. Would ~128 be enough? or
> something larger?

Well, if it has to be limited I'd put it _way_ up there.  1024 or something...

-Luke

[Blocks-development] 85 char filename limit

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: Re: [Blocks-development] V0.16 Release announcement
>Date: Mon, 28 Aug 2000 22:28:10 +0200
>
>On 28 Aug 2000, at 18:01, Blat Froop wrote:
>
> > Michael will be running a V0.16 public test server which
> > you can connect at mspencer.net:8016
>
>Works fine. Uploading is significantly faster now. The 85 character
>limit is a bit annoying :(. Can't we make it twice as long?

Yes, now that we support multiple header blocks we dont have to
be so careful with the size of the filename etc.

I'll increase it in V0.17. Would ~128 be enough? or
something larger?

ttfn

PG.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [Blocks-development] V0.16 Release announcement

[<lu...@et...>]

* Erik Moeller wrote:
> Works fine. Uploading is significantly faster now. The 85 character 
> limit is a bit annoying :(. Can't we make it twice as long?

Yea, that was annoying enough to make it the first bug/feature request
over at sourceforge. :-)

0.16 is up there as well.  Whee!

I'll be moving over the next few days so I'm taking my server down.  One
of my cow-orkers is setting up one at his house as I write, however.

-Luke

Re: [Blocks-development] V0.16 Release announcement

[Erik M. <mo...@sc...>]

On 28 Aug 2000, at 18:01, Blat Froop wrote:

> Michael will be running a V0.16 public test server which
> you can connect at mspencer.net:8016

Works fine. Uploading is significantly faster now. The 85 character 
limit is a bit annoying :(. Can't we make it twice as long?

Regards,
Erik

-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

Re: [Blocks-development] V0.16 Release announcement

[Benjamin M. B. <br...@kr...>]

http://blocks.kripto.org / http://www.kripto.org/blocks is now updated to
the version 0.16 information.

Sorry it took a little longer than desired, as I worked all day ;D

-Ben

On Mon, 28 Aug 2000, Blat Froop wrote:

> V0.16 is now ready. The web page will (hopefully) be updated
> soon to let you all get the most recent binaries (including
> Linux binaries!) and source (which now builds on Linux without
> hacking!).
> 
> Michael will be running a V0.16 public test server which
> you can connect at mspencer.net:8016
> 
> Many thanks to everyone who has contributed directly and
> indirectly!
> 
> Regards,
> 
> PG.
> 
> Here is a summary of whats new...
> 
> 1) New protocol version message
> 
>    * V0.16 will not connect to previous versions of Blocks. This
>      should stop the sort of interoperability problems we saw
> 	 when moving from V0.14 to V0.15.
> 
> 2) Big Files
> 
>    * Support for files > 250Mb. New limit should be 2Gb.
>    * Files which are larger than 10% of the cache size are
>      not cached when routing. This stops large files from
> 	 trampling intermediate servers with small caches.
> 
> 3) Readvertisements
> 
>    * Only non-local files are readvertised (same as V0.15)
>    * Only servers with an uptime > 60secs readvertise files.
>    * Readvertisements are never routed or broadcast.
>    * Latest 512 adverts are immediately readvertised on
>      connection, then one every 15 seconds per connection,
> 	 for another 4096 ads (over some 17hours or so).
> 
> 4) Enhanced PRNG
> 
>    * Entropy from DH Keys fed back in much better
>    * Fixed PRNG bug (to do with connection management logic)
>    * PRNG now explicitly advanced after uploads, downloads,
>      and connections.
> 
> 5) Faster Uploading
> 
>    * V0.15 had an artificial limit of ~20 blocks/sec for
>      inserting into the cache. This limit has been removed
>      and upload times should be bound by your disk speed.
> 
> 6) Builds on Linux
> 
>    * Should build clean on most Linux variants, as well as
>      WIN32 and Solaris.
> 
> Stuff which didnt make it this time...
> 
>    * Resuming download from local cache.
>    * Automatic download route switching.
>    * Sticky files.
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at 
> http://profiles.msn.com.
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development
> 

[Blocks-development] V0.16 Release announcement

[Blat F. <pet...@ho...>]

V0.16 is now ready. The web page will (hopefully) be updated
soon to let you all get the most recent binaries (including
Linux binaries!) and source (which now builds on Linux without
hacking!).

Michael will be running a V0.16 public test server which
you can connect at mspencer.net:8016

Many thanks to everyone who has contributed directly and
indirectly!

Regards,

PG.

Here is a summary of whats new...

1) New protocol version message

   * V0.16 will not connect to previous versions of Blocks. This
     should stop the sort of interoperability problems we saw
	 when moving from V0.14 to V0.15.

2) Big Files

   * Support for files > 250Mb. New limit should be 2Gb.
   * Files which are larger than 10% of the cache size are
     not cached when routing. This stops large files from
	 trampling intermediate servers with small caches.

3) Readvertisements

   * Only non-local files are readvertised (same as V0.15)
   * Only servers with an uptime > 60secs readvertise files.
   * Readvertisements are never routed or broadcast.
   * Latest 512 adverts are immediately readvertised on
     connection, then one every 15 seconds per connection,
	 for another 4096 ads (over some 17hours or so).

4) Enhanced PRNG

   * Entropy from DH Keys fed back in much better
   * Fixed PRNG bug (to do with connection management logic)
   * PRNG now explicitly advanced after uploads, downloads,
     and connections.

5) Faster Uploading

   * V0.15 had an artificial limit of ~20 blocks/sec for
     inserting into the cache. This limit has been removed
     and upload times should be bound by your disk speed.

6) Builds on Linux

   * Should build clean on most Linux variants, as well as
     WIN32 and Solaris.

Stuff which didnt make it this time...

   * Resuming download from local cache.
   * Automatic download route switching.
   * Sticky files.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [Blocks-development] V0.16 progress

[Blat F. <pet...@ho...>]

>From: lu...@et...
>To: Blat Froop <pet...@ho...>,        
>blo...@li...
>Subject: Re: [Blocks-development] V0.16 progress
>Date: Fri, 25 Aug 2000 09:55:50 -0400
>
>* Blat Froop wrote:
> > At the moment the cache is just a big FIFO ring which isnt
> > as bad as it sounds. The distributed nature of Blocks means
> > that files which expire will get replicated due to routing
> > if they are really popular, and the cacheing system itself
> > means that LRU wouldnt necessarily favour the most popular
> > files... just the most popular node for that file.
>
>Hurm.  Too lazy to check the code:  Will my machine cache something that
>it already has in cache?

Nope, but once the original expires and is overwritten it can
be cached again.

>
> > This is a good issue for debate. Are sticky files a
> > good idea?
>
>Quoting from an old boss:  "Any feature that can't be turned off is a bug."
>
>
>So, when do we get the todo list up on sourceforge? :-)

I tried to mess around with that sourceforge thing but didnt
get anywhere quickly. I'd rather keep stuff on the web page
unless its simple to set up.

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] V0.16 progress

[<lu...@et...>]

* Blat Froop wrote:
> At the moment the cache is just a big FIFO ring which isnt
> as bad as it sounds. The distributed nature of Blocks means
> that files which expire will get replicated due to routing
> if they are really popular, and the cacheing system itself
> means that LRU wouldnt necessarily favour the most popular
> files... just the most popular node for that file.

Hurm.  Too lazy to check the code:  Will my machine cache something that
it already has in cache?

> This is a good issue for debate. Are sticky files a
> good idea?

Quoting from an old boss:  "Any feature that can't be turned off is a bug."


So, when do we get the todo list up on sourceforge? :-)

-Luke

Re: [Blocks-development] V0.16 progress

[Blat F. <pet...@ho...>]

>From: "Michael Spencer Jr." <bl...@ms...>
>To: "Erik Moeller" <mo...@sc...>,        
><blo...@li...>
>Subject: Re: [Blocks-development] V0.16 progress
>Date: Thu, 24 Aug 2000 22:59:04 -0500
>
>My thought is...LRU cache entry expiry (which is what we had been using,
>right) is pretty universally a good thing.  LRU flushes out the things that
>haven't been used in a while, by definition.  So if all blocks are weighted
>equally (like in a hard disk) LRU is pretty close to optimal.

LRU was the original intention but thats not quite the way it
works right now. As you might have noticed in the source code
there is a lot of "// TODO: move to top of list?" comments.
These are (some of) the places that would need to be adjusted
to implement a LRU cache.

At the moment the cache is just a big FIFO ring which isnt
as bad as it sounds. The distributed nature of Blocks means
that files which expire will get replicated due to routing
if they are really popular, and the cacheing system itself
means that LRU wouldnt necessarily favour the most popular
files... just the most popular node for that file.

There is probably a thesis here somewhere :-)

>
>However, blocks are not evenly weighted, because of two things:
>
>1)  if the server's user placed a file there himself, he's probably more
>interested in keeping that file available than he is in using the space to
>cache other files.  So those blocks are special.

Thats the 'sticky' file idea. However, by marking the blocks
as special you lose plausible deniability that the file
was proxied into cache and can therefore be held liable
for publishing. Of course, in order to prove this your
computer would have to be captured while its actively running
the server since the cache is encrypted, but that might
be too much for some. Currently you can swear under oath
that you dont know whether or not you uploaded the file
since any file you might have uploaded may have been
expired and replaced.

This is a good issue for debate. Are sticky files a
good idea?

>
>2)  if a file is composed of multiple blocks, if you expire one block 
>you've
>made the whole file unavailable.  This doesn't count if you actually have 
>no
>idea that all these blocks go together...but if you have some concept that
>the blocks all form one file, then you should weight the blocks together 
>and
>expire them all at once.

Blocks stores files as header and data blocks in its FIFO cache
like this...

HDDDDDDDDDDDDDD...

so the header block expires before the data blocks do. This
effectively expires the whole file. However, should a request
to a further away server be routed through the server with
this cache, the server may intercept the requests for data
blocks that it has... therefore speeding up the download
and avoiding the problems of people downloading 90% of
a huge file before they find out that the end has expired :-)

>
>So I think together this yields:
>
>Sticky files and blocks.  Already being worked on.
>
>Different LRU behavior?  Perhaps take a weighted average of block age vs.
>block-group size -- a 500 block file that's 1 day old will have similar
>weight to a 100 block file that's 5 days old.  So larger files 'gain 
>weight'
>:) faster and drop off the cache sooner.
>
>Does this scenario fail easily?

Hmmm... a 1Gb file consists of 20000 blocks... video archives
might have a short lifespan.

>
>Suppose I have a 2 GB cache, filled 1.99 GB full of sticky user-uploaded
>files.
>
>I now have 160 blocks to fill with data as it comes around.  Suppose 
>someone
>transfers a 159 block file through me, finishes the file...I advertise
>it...and I recognize that file to be a whole file, not a disconnected bunch
>of blocks.  No other traffic is going through me while this file is being
>transferred through me.
>
>Then suppose it's a popular file.  Lots of people start requesting it from
>me...so I'm servicing at least one request for at least one part of the 
>file
>at all times.  It's pretty much impossible for that file to gain any
>'discard weight' -- any file size multiplied by zero age is still zero.  So
>that file is effectively locked in my cache until people stop requesting it
>for even one second.

Remember its quite difficult to acertain what a 'popular' file
is at any one server.

>
>So what do I have with that one-block cache?  A complete inability to
>download anything.  (Right?)  I can only route blocks for other people.  
>And
>only one block at a time -- if someone has a 1k/sec connection to me, that
>will be the only block (besides the popular file and the files I'm sharing)
>I can transfer until the transfer is done.  I will also not be publishing
>any new files -- I would need both the header and all of the (non-zero) 
>data
>blocks...and I can't store that in one block.

Sticky files will probably have to exist out-of-cache or
there has to be at least some safeguards that the public
cache space is big enough. Zero length files are not allowed.

>
>Is that graceful degradation, in those extreme circumstances?  Is it
>considered graceful, considering that this one popular file is being
>downloaded *constantly* multiple times.  If that's all my node is good
>for...is that enough?
>
>BTW, if this seems costly to compute...you can just start purging by LRU
>when the free cache hits a low water mark, and keep purging until you hit a
>high water mark.
>
>What do you think?

There are 16384 blocks per Gb of cache, and each cache entry
uses (at least) 16bytes to store the block ID (1Mb per Gb).
But in order to encourage large caches we dont really have
that much CPU available to do housekeeping so ideally we
need an incremental algorithm to do this. There are lots of
good and useful observations in what you have said above,
but I dont think we have a crystal clear view of the
complete problem set to be solved (yet).

Yet another thesis for someone :-)

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] V0.16 progress

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: Re: [Blocks-development] V0.16 progress
>Date: Fri, 25 Aug 2000 02:51:51 +0200
>
>On 24 Aug 2000, at 18:41, Blat Froop wrote:
>
> > * Files are only cached if they are < 10% of the cache size.
>
>Why?

Well, I think we have to assume that most caches in the Blocknet
will be < 4Gb or so, therefore routing 2 or 3 large files of 1GB
or so will effectively destroy the contents of the cache. Seems
logical to store large files in large caches.

>
>Is resuming from cache implemented?

Resuming from other peoples caches has always been implemented,
but you're right we need to be able to resume from the local
cache as well. I'll see if there is a quick fix before release.

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] V0.16 progress

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

My thought is...LRU cache entry expiry (which is what we had been using,
right) is pretty universally a good thing.  LRU flushes out the things that
haven't been used in a while, by definition.  So if all blocks are weighted
equally (like in a hard disk) LRU is pretty close to optimal.

However, blocks are not evenly weighted, because of two things:

1)  if the server's user placed a file there himself, he's probably more
interested in keeping that file available than he is in using the space to
cache other files.  So those blocks are special.

2)  if a file is composed of multiple blocks, if you expire one block you've
made the whole file unavailable.  This doesn't count if you actually have no
idea that all these blocks go together...but if you have some concept that
the blocks all form one file, then you should weight the blocks together and
expire them all at once.

So I think together this yields:

Sticky files and blocks.  Already being worked on.

Different LRU behavior?  Perhaps take a weighted average of block age vs.
block-group size -- a 500 block file that's 1 day old will have similar
weight to a 100 block file that's 5 days old.  So larger files 'gain weight'
:) faster and drop off the cache sooner.

Does this scenario fail easily?

Suppose I have a 2 GB cache, filled 1.99 GB full of sticky user-uploaded
files.

I now have 160 blocks to fill with data as it comes around.  Suppose someone
transfers a 159 block file through me, finishes the file...I advertise
it...and I recognize that file to be a whole file, not a disconnected bunch
of blocks.  No other traffic is going through me while this file is being
transferred through me.

Then suppose it's a popular file.  Lots of people start requesting it from
me...so I'm servicing at least one request for at least one part of the file
at all times.  It's pretty much impossible for that file to gain any
'discard weight' -- any file size multiplied by zero age is still zero.  So
that file is effectively locked in my cache until people stop requesting it
for even one second.

So what do I have with that one-block cache?  A complete inability to
download anything.  (Right?)  I can only route blocks for other people.  And
only one block at a time -- if someone has a 1k/sec connection to me, that
will be the only block (besides the popular file and the files I'm sharing)
I can transfer until the transfer is done.  I will also not be publishing
any new files -- I would need both the header and all of the (non-zero) data
blocks...and I can't store that in one block.

Is that graceful degradation, in those extreme circumstances?  Is it
considered graceful, considering that this one popular file is being
downloaded *constantly* multiple times.  If that's all my node is good
for...is that enough?

BTW, if this seems costly to compute...you can just start purging by LRU
when the free cache hits a low water mark, and keep purging until you hit a
high water mark.

What do you think?

--Michael Spencer
bl...@ms...

----- Original Message -----
From: "Erik Moeller" <mo...@sc...>
To: <blo...@li...>
Sent: Thursday, August 24, 2000 7:51 PM
Subject: Re: [Blocks-development] V0.16 progress


> On 24 Aug 2000, at 18:41, Blat Froop wrote:
>
> > * Files are only cached if they are < 10% of the cache size.
>
> Why?
>
> Is resuming from cache implemented?
>
> Regards,
> Erik
>
> --
> Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
> Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
> The Origins of Peace and Violence: <http://www.violence.de>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] V0.16 progress

[Erik M. <mo...@sc...>]

On 24 Aug 2000, at 18:41, Blat Froop wrote:

> * Files are only cached if they are < 10% of the cache size.

Why?

Is resuming from cache implemented?

Regards,
Erik

-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

[Blocks-development] V0.16 progress

[Blat F. <pet...@ho...>]

V0.16 is now complete.

* Protocol version message is now in place,
  and connection to previous versions results in immediate
  disconnect.

* Files > 250Mb are now supported.

* Files are only cached if they are < 10% of the cache size.

* Uploading slugs have been removed which should mean
  much quicker uploads in most cases.

* Should compile clean on Linux without editing anything.
  (We'll need to change the compile text on the web page
   when we advertise this).

* Sticky files will have to wait until V0.17

At the moment Im trying to give it a bit of a test, which is
a little more time consuming than usual because of the large
files involved. Hopefully it'll be ready for the web page and
general use this weekend.

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] New blocks website address.

[Benjamin M. B. <br...@kr...>]

Just letting you all know that blocks now has a subdomain, and can also be
located at http://blocks.kripto.org

In regards to the FTP issue, I am sorry that it is taking me so long. I
will place the files on the server when you email them to me. Also, if
this arrangement isn't working out, I'd be happy to make it refresh to
another site.

-Ben

[Blocks-development] infoAnarchy.org

[Erik M. <mo...@sc...>]

In the past weeks, I and Eric Hanson of www.shouldexist.org have been 
working on infoAnarchy, a site that covers

	- Reviews of File Sharing / Anonymity Tools 
	- Announcements of New Releases 
	- Ideas and Concepts 
	- Legal Proceedings, Statements and other Relevant News 
	- Viewpoints 
	- ... 

Basically anything that is relevant on the subject of information 
sharing. Please check out the site at

	http://infoanarchy.org

The site is Scoop-based which means that users can submit stories or 
vote on stories submitted by others. Users can also comment on 
stories and rate each other's comments.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

Re: [Blocks-development] Trust Network standards document v0.02

[Blat F. <pet...@ho...>]

>From: "Michael Spencer Jr." <m...@ms...>
>To: <blo...@li...>
>Subject: [Blocks-development] Trust Network standards document v0.02
>Date: Fri, 18 Aug 2000 18:01:06 -0500
>
>This is an early, partial draft of the web-of-trust standards document.  It
>doesn't detail enough layers to form a complete web-of-trust yet.
>
>Someone had recommended transferring signatures with the file adverts.  If
>that gets implemented, that would replace the bottom layer -- the transport
>mechanism for all this crypto material.
>
>Do we need overseas developers now?  We don't want to run afowl of United
>States cryptographic technology export restrictions...and we definitely
>don't want someone in the US to get the bright idea that...if they merely
>classify distributed filesharing technology to be a munition, they could
>legally do bad things to the authors of these programs.  :(

Crypto upto 64bits in strength is freely exportable. All the
current crypto code in Blocks was created outside of the US,
and AFAIK there arent any import restrictions here :-)

I dont think there are any crypto restrictions on authentication
mechanisms like digital signatures, so long as the data itself
is not encrypted.

No information in Blocks is password encrypted. However,
cached and transmitted data are secured by transient session
keys.

I think I'll have a read of you docs now :-)

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Trust Network standards document v0.02

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

This is an early, partial draft of the web-of-trust standards document.  It
doesn't detail enough layers to form a complete web-of-trust yet.

Someone had recommended transferring signatures with the file adverts.  If
that gets implemented, that would replace the bottom layer -- the transport
mechanism for all this crypto material.

Do we need overseas developers now?  We don't want to run afowl of United
States cryptographic technology export restrictions...and we definitely
don't want someone in the US to get the bright idea that...if they merely
classify distributed filesharing technology to be a munition, they could
legally do bad things to the authors of these programs.  :(

Please, please, give me comments, propose changes, and wildly speculate out
loud on the mailing list.  This isn't just 'my baby' -- my vision starts
running a bit thin after about the fourth layer.  This is only a framework.
It's up to you guys to come up with cool and useful ways to use the
framework.

--Michael Spencer
bl...@ms...

-----START OF STANDARDS DOCUMENT-----
BLOCKS NETWORK PUBLIC-KEY CRYPTO SPECIFICATION

Distribution:  unlimited

The current version of this file is:  0.02
If you make a change to this document, please add your changes to the
changelog at the end and increment the version number.  For synchronization,
please email changes, comments, vague ideas, and premonitions to
bl...@ms... to prevent version number conflicts between multiple
authors.  I'll try to make sure everything makes it in.

------------------------------------------------------------------------

The trusted file network is composed of several layers.  The lower (inner)
layers are more concrete and basic things:  a file, a signature, a packet.
The higher (upper) layers are more abstract but meaningful things:
identities, trust, content.

**********

BOTTOM LAYER:  FILES

All Trust Network data exists within files.  Files are cached in a directory
on the local machine, or can be searched for on the Blocks Net.

----------

Filenames:

public key:
pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXX == fingerprint of public key, 40 hex digits
obtain fingerprint with:  gpg --fingerprint
add the public key to your keyring with:  type pk-XXXXXXXXXX...XXXX | gpg

key signature:
sig-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
YYYYYYYYY

XXXXX == fingerprint of public key being signed, 40 hex digits
YYYYY == fingerprint of signing key, 40 hex digits
verify the signature with:  type sig-XXXX...YYY | gpg

content signature (or other message about content):
cs-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

XXXXX == fingerprint of signing key, 40 hex digits
ZZZZZ == content-hash of file being signed, 32 hex digits
verify the signature with:  type cs-XXXX...ZZZ | gpg

----------

File object descriptions:

public key:
A public key is a piece of cryptographic material, generated by GPG (or
equivalent) and used to verify signatures made on content and on other keys.
You should read and understand how GPG and public-key cryptography works
before continuing.

key signature:
This should be a file which contains a machine-readable statement of trust
about a key ("I certify that the world should trust this key this much"),
which is signed with a GPG signature.

content signature:
This should be a file with a machine-readable statement of trust about
content, which is signed with a GPG signature.  Details about the content of
the key and content signatures will be detailed in a higher layer.

**********

SECOND LAYER:  CRYPTOGRAPHIC MATERIAL

The Trust Network relies upon signatures made with cryptographic material to
validate trust information.  This cryptographic material is currently
created and verified with GPG, but the content of the messages the
cryptographic material validates must be interpreted by hand or with another
program.

This layer doesn't care about what the messages actually mean.  This layer
only creates and validates keys and signatures.

----------

Create a key:

All of these commands should be run from the directory you have GPG
installed in.

1)  Create the public key pair
At the command prompt, type:  gpg --gen-key
When asked for the type of key you want, select 1:  DSA and ElGamal
When asked for a keysize, type in 2048
Tell it Yes, you really need such a large keysize.
Key is valid for: 0 (does not expire)
When asked if this is correct, say Yes.
When asked for a real name, type:  BLOCKS
When asked for an email address, just hit enter
When asked for a comment, type your user name or alias.
(where <username> is your preferred user name, alias, whatever...just like
your user name on Napster would be.)
FIXME:  Should we have some kind of guidelines about the uniqueness of
usernames?  Keys will be selected by Key ID anyway...but the username field
will be the human-readable part of the key.
When asked to confirm, type O for OK.
Enter a pass phrase to protect your secret key -- you will use this pass
phrase whenever you create a signature using that key.
Retype the pass phrase.  If you mistyped the pass phrase, you will need to
retype it again twice.
After you type the pass phrase, a secret key will be created and added to
pubring.gpg and secring.gpg in the current directory.
2)  Export the public key to a file
At the command prompt, type:  gpg --export -a <username> > pubkey.txt
(where <username> is the name, handle, or nick you picked for yourself in
step 1.)
3)  Change the filename to the Blocks standard
At the command prompt, type:  gpg --fingerprint <username>
(where <username> is the name, handle, or nick you picked for yourself in
step 1.)
Note the "Key fingerprint =" line -- you'll need to type those hex digits in
by hand.
At the command prompt, type:  ren pubkey.txt
pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
(where XXXXXXX matches the Key fingerprint line's contents -- 40 hex digits
with no spaces)
4)  copy your new pk- file to your blocks/trustnet directory.
FIXME:  I just made up blocks/trustnet, analogous to blocks/cache and
blocks/files.  If someone else has a better name in mind, please suggest it.
5)  Upload your pk- file to the network!

----------

Add someone else's key to your keyring:

1)  Find and download the pk- file from Blocks.
2)  Copy the pk- file to your GPG directory
3)  Add the key in the pk- file to your public keyring
At the command prompt, type:  type pk-XXXXX...XXX | gpg
You should see output that lists the key just added, with BLOCKS (username)
on the right.  If you are prompted for your passphrase, or you see any other
strange output, the file you processed wasn't a public key.

----------

Create a signature:

1)  Prepare the file or packet you're going to sign.  Note that for a sig-
or cs- file, the contents of the file you're signing is defined in a higher
layer.  If no higher layers have been defined, just make something up.
2)  Create a cleartext signed file from the original packet.
From the command line, type:  gpg --clearsign --textmode <filename>
When asked for the pass phrase for your secret key, type it in.
GPG will create another file.  If your source file had an extension (like
.txt), the output file will have the original extension removed and .asc
appended.  If the source file did not have an extension, the output file
will have .asc appended.
3)  Change the filename to the Blocks standard
If the file is a signature of another key, use pk-XXXXX-YYYYY (40 X's and 40
Y's).  If the file is a signature of a file, use cs-XXXXX-ZZZZZ (40 X's and
32 Z's).  If the file is some other kind of file (pertaining to a message
board or chat room or something else) use that file type's standard.
4)  Upload the file to the network!

----------

Confirm a signature:

1)  Copy the signed file to your GPG directory.
2)  Verify the signed file
From the command line, type:  gpg filename
If you see:
gpg: Signature made xx/xx/xx xx:xx:xx  using DSA key ID XXXXXXXX
gpg: Good signature from "BLOCKS (username)"
Then you know that key ID XXXXXXXX did indeed sign that file.
If you see:
gpg: Signature made xx/xx/xx xx:xx:xx  using DSA key ID XXXXXXXX
gpg: BAD signature from "BLOCKS (username)"
Then you know the file you're processing has been corrupted or tampered with
in some way.

FIXME: Would it make more sense to use the 8-digit key ID instead of the
40-digit Fingerprint?

**********

This is only the first third of the trust network.  It isn't useful
yet...but people have a chance to practice the procedures and understand the
concepts in the first two layers.  Once we agree on standards for the next
couple layers, we can start creating and trading files.

------------------------------------------------------------------------

Version 0.01:  mspencer  8/2/2000
Created the file name formats, and put very basic directions in about what
to do with the files.

Version 0.02:  mspencer  8/18/2000
Added layer structure, explained the first two layers in detail.  First
public release.
-----END OF STANDARDS DOCUMENT-----