Re: Dissolving Choke Points (fwd)

[ichudov@algebra.com (Igor Chudov @ home)]

> From: ####### ### <###@###.com>
> To: ichudov@algebra.com
> Subject: Re: Dissolving Choke Points
> 
> ichudov@algebra.com writes:
>  > i do have unix (linux) and stuff, but i can't take a lot of subscribers
>  > -- maybe 200-300 or so.
>  > 
>  > i actually wrote a proposal for a mailing list without a central control
>  > point, with several advantages being impossibility of control, absense
>  > of a single point of failure, and cryptographic verification of honesty 
>  > of moderators.
>  > 
>  > if there is any interest, i will post it here.
> 
>      Please do.
> 
> Regards,
> 
> ####### ###

Here, I propose a new scheme for the Cypherpunks mailing list that would

1) Ensure that no one person is able to take over the control over the list
2) Ensure that there will be no single point of failure, i.e., shutdown
   of any single computer will not kill the list
3) Ensure that even people with relatively small Net resources can help
   keep the list afloat.

The idea is as follows: even though Cypherpunks is one group, the group
will be based on multiple mailing lists with identical content. These
lists may be named, for example, cypherpunks@algebra.com,
cypherpunks@toad.com, and cypherpunks@netcom.com (obviously, these names
are used as an example only).

Any user is free to subscribe to any of these lists. All of these lists
will interact with each other in the following way: 

1) Each node would forward ALL incoming submissions to a) all other nodes
   and b) to all subscribers "attached" to the node
2) Each node will send information about all new subscriptions to 
   each other node.

The following procmail recipes for cypherpunks@ accounts may be used to 
ensure quick forwarding: 

# is it sent to cypherpunks (some spams will be trashed here)
# and is it not a mail loop?
:0
* ^TOcypherpunks
* !^X-Loop:
{
  #
  # This recipe removes duplicates!
  #
  :0 Wh: msgid.lock
  | formail -D 32768 msgid.cache

  # forward it to other cypherpunks lists
  :0 c
  !cypherpunks@netcom.com cypherpunks@toad.com

  # send it to all local subscribers
  :0 c
  !majordomo -some -arguments

  # store the checksum and message-id for honesty verification (see below)
  :0
  |accounting
}

# suSCRibe/unsuSCRibe recipes go here

This scheme ensures that the list is run in a cooperative fashion and
can be maintained by a number of individuals without any one of them
having an expensive internet connection or being "in charge". It also
ensures that even if one node fails, traffic can be re-routed to other
nodes. Just as well, it ensures that any attempts of cheating will be
noticed: it is easy to write a bot that would subscribe to all of these
lists and see if any messages get "lost".

Users can send their articles to only one node, or, if they feel
paranoid, to several nodes at once. All we need is to make sure that 
all Message-IDs of outgoing messages are unique at every node.

Honesty verification: 

I suppose that there may be some more elaborate, crypto-based schemes 
to control and monitor article distribution. For example, there can be
another list, cypherpunks-control, where each of the nodes posts a 
publicly available signed summary of checksums of articles that went
through, and individual users would be able (with the help of s simple
client program) to verify that

        1) They received these articles
        2) That summaries received from all nodes are identical
        3) That all articles were received by all nodes


They do not HAVE to do it, but they can if they want. If they do, there
will be no way for list maintainers to censor anything.

If a node goes down or if the users' verification scripts indicate a 
potential for cheating, they can resubscribe to some other node and
let everyone else know what's going on.

My proposal strikes me as fairly simple and potentially workable. Even
though 90% of the users will never get to usnig the verification
mechanism, it will ensure honesty.

Note also that this mechanism is a gross simplification of the way 
USENET works, so some may vouch for a usenet group instead. 

Your opinions will be appreciated.

        - Igor.