[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.
Agreed.

>    *  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
keyspace.

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
second?

> 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