[RC5] Lack of communication, Keyspace plot, Eyegive

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Wed Jun 24 09:28:31 EDT 1998

     last question first:
     remaining question:
     Comments about off-line computers...
     Off-line computers tend to be older and slower (and thus ineligible 
     for expenditures to attach them to the network).  Also, the 
     sneaker-netting required to maintain an off-line farm is not 
     insubstantial.  Most of these farms need to run a *very* long time 
     to keep their operators from getting tired of them quickly.
     Thus, in a very real sense, the subspaces that off-line clients are 
     cracking need to be disjoint from the subspaces that on-line clients 
     are cracking.  Although HD space is relevant to this, speed isn't 
     because the load from off-line farms is *very* uneven.  My farm 
     transacted several thousand blocks in about 15 minutes every three 
     months.  (Although it's off now since there isn't enough time 
     between resends to justify its operation.)  Capacity planning for 
     the off-line clients through the current proxy network will not be 
     successful.  So either
     1) the off-line clients are treated as an aberration and no planning 
     is made to handle their non-standard utilization requirements, or
     2) some back-channel is created for off-line farms to use.
     Neither of those is a hardware issue.
     Some comments about the second of those alternatives, since the 
     first is what is currently being done.  Off-line assignments ought 
     to be in contiguous segments.  This makes the detection of dropped 
     and lost blocks much easier.  There needs to be buffer management 
     tools that allow the off-line administrator to coalesce and 
     subdivide buff-*s so that one mega-fetch and one mega-flush are all 
     that need be performed for the entire farm.  (Perhaps these are the 
     cases for pproxies, but it seems silly to set up a pproxy to feed an 
     off-line farm.)  A version of the client that does *not* detect that 
     another copy of the client is already running is an important 
     addition to the off-line administrator's toolkit (so that fetches 
     and flushes for off-lne clients don't require shutting down the 
     administrator's cracking client.)  In fact, this oblivious client 
     shouldn't even be able to crack keys, it should be the networking 
     and buffer management code only.
     Anyway.  Enough complaining about how the current D.Net setup makes 
     off-line farming hard.
            -- Eric Gindrup ! gindrup at Okway.okstate.edu

______________________________ Reply Separator _________________________________
Subject: [RC5] Lack of communication, Keyspace plot, Eyegive 
Author:  <rc5 at lists.distributed.net> at SMTP
Date:    6/23/98 12:09 PM

Is there any method to check how much money has been raised through Eyegive?
If the money raised is "substantial", I think D.Net could allocate some 
money to increase the size and power of the master key server and possibly 
increase the number of open keyspaces. Hence, off-line computers can have 
more time to do the calculation. Am I right?
If the money is available, what is the equipment that D.Net would like to 
buy most?
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net 
rc5-digest subscribers replace rc5 with rc5-digest

To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list