[rc5] Future of Distributed Computing

James Mastros root at jennifer-unix.dyn.ml.org
Thu Oct 23 21:40:13 EDT 1997

On Thu, 23 Oct 1997, Sebastian Kuzminsky wrote:
> nataylor at nmt.edu (Nathan Taylor) wrote:
> ] I have chosen not to go on to the 64 challenge.  As far as I'm concerned,
> ] the encryption thing has been done.  Anything from here on out is acedemic.
> ] I won't be doing primes, either.  It's too abstract a concept for me to
> ] really enjoy.  SETI sounds fun, but the problem is that project has no
> ] definite end.  So, for now, my idle cycles will go unused.  I'm waiting for
> ] the NEXT BIG PROJECT(tm).
>    The Mersenne primes project is, as the distributed.net web pages
> point out, a never-ending filler.  Please enlighten a poor
> math-ignoramus:  what use are Mersenne primes?
A prime number of the form 2^n-1.

>    The SETI project is really cool.  The data is quite limited in scope,
> but the sexiness factor is pretty high.
Exactly.  *REAL HIGH*!

>    Of these three, i would work on RC5-64.
I wouldn't; I would work on SETI.

> ]                                             What about distributed 3D
> ] picture rendering?
>    Hmmm...
> On the clients side, that saturates a
> 14.4 Kbps connection.  The distributed.net computer can produce this
> data at almost 100 MB/s.  Only most well-connected servers on the
> internet could accept data at that rate.
>    With todays infrastructure, in this case, distributed.net would turn
> a CPU bound problem into an I/O bound one.  
> ]                                                                   What if
> ] I was just performing a complex calculation on a huge spreadsheet and parts
> ] of it got distributed?  How about a network where every computer was free 
> ] to use the other computers' idle time.  
>    Truly distributed processing has a practical problem that seems
> nearly insurmountable:
>    How do you protect against malicious participants?
Yep... BIG problem.  Can you say bunda at buceta.caralho.org?  (I can't).

>    In some cases the fakery is easy to detect ("Hey, this key decrypts
> the cyphertext to gibberish!"), but in some cases it cannot be done
> without ACTUALLY performing the whole computation to verify the result
> (the prime-finding problem has this property).
As does distributed chess.  I submit a move that results in easy checkmate
(for Deep Blue, not Deep Cow).

>    There are means of alleviating this problem, but not of solving it in
> the general case.  You could submit the same job to N different clients,
> and use a voting system to decide the result.  
But that means n times the work, and still a n*(% of fake positives) chance
of getting a fake positive.  Also, this won't help at all for a honest false
positive (assuming that both groups are running the same client).

> You could use a reputation system:  Alice detects Bobs fakery and adds him 
> to a more-or-less global black list.
This is the best (most elegant/general) thing I see, but still has a big
problem: how Alice detects Bob's despicable behivor.

>    Some applications i'd like to see for distributed.net are:
>    *  A distributed chess engine
> 	 The chess problem is quite different from the RC5 problem.  I
> 	 am eager to see how the v3 protocol will allow for two such
> 	 diverse algorithms.  The chess problem may be too
> 	 network-intensive for the distributed.net computer.  The sort
> 	 of CPU power that distributed.net has available should be able
> 	 to beat Deep Blue without too much trouble, given wide pipes.

>    *  An on-demand SSL/Unix crypt() cracker
> 	 Like the RC5 crack, but let users submit what they want
> 	 cracked.  No better way to drive the point home...

I like, definitly.  Although there are many different crypt() alogrithims.
Also, doing a pure-brute-force method crypt crack is, in general, not a Good
Thing, since humans tend to use passwords from a certian subset of the

Also, I just thought of a fairly cool one:  a distributed web-search engine.
Each client would get a starting URL from the master server (via a network of
proxies, naturally), and get that page.  Then extract its vital statics, and
send it back up to the master servers.  (As a slight optmisation, get all
the URLs that you want to buffer from that page, and send the rest up to d.n
(better: send all of them, but mark some as taken by you.).)  IO bound, yes,
but a good choice for those with tons of IO to burn.

It seems to me, however, that the chess and rendering ideas are going to be
data-bound.  That is to say, for chess what do we do while we are waiting
for Deep Blue to take his turn, and how many images do you want rendered per

> Sebastian

	-=- James Mastros
		   Current Bovine Rate: ~5894.11 mkeys/sec
	       If Keys were dollars, we could pay off the U.S.
		       National Debt in 14.70 minutes.
     -=- http://rc5stats.distributed.net/statbar.html (Tue Oct 21 1997)

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list