[rc5] Random keyblocks

Eric Gindrup gindrup at okway.okstate.edu
Tue Aug 26 09:33:19 EDT 1997


        Perhaps better would be to hash the "block-space" so that the 
     hashed sequence of blocks would be random enough to wander all over 
     the keyspace.  Then percentages completed could be reported with 
     incoming blocks to the client.  So a random block could be generated 
     from the last x% of the hashed keyspace where x is the unchecked 
     percentage.
        There would always be some marginal percentage that a random block 
     was wasted, but that percentage could be controlled by limiting the 
     interval from which the proxies are assigning blocks under the 
     assumption that the percentage complete indicator is updated 
     occasionally at the client.
     
        Also, clients aren't expected to connect to get tardy blocks.  
     Tardy blocks are expected to be assigned infrequently with a regular 
     block.  So, if that client ever can't connect to get more blocks, it 
     runs through its tardy blocks (or, equivalently, "highly useful 
     'random' blocks") and then generates random blocks until it can report 
     all completed work to a proxy.
        The overhead of transmitting or storing the occasional tardy block 
     is very low.  Furthermore, if one were concerned that a fast client 
     with a reliable connection were to collect too many tardy blocks, then 
     perhaps the client should have (yet another) option to limit the 
     number of tardy blocks that it will collect.  Either it can work on 
     them when the tardy limit is reached, or it can refuse to accept new 
     tardy blocks.  A refused tardy block would just become tardy again and 
     be reassigned to someone else.
        The idea is that tardy blocks are assigned when the connection to 
     the proxy is working and are only worked on when that connection is 
     bad.  This increases the utility of the offline work over that of 
     purely random block generation.
     
        Finally, the only reason I can see for supporting purely random 
     block generation is concern that clients are improperly reporting 
     completion of blocks.  Perhaps a rogue client or some such is 
     misreporting block completions.  The random blocks would thus serve as 
     a check that reported blocks actually don't contain the desired key.  
     Simplicity of coding is also an issue in random block generation, but 
     the simplest design is just to exit.
            -- Eric Gindrup ! gindrup at Okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: [rc5] Random keyblocks
Author:  <rc5 at llamas.net> at SMTP
Date:    1997/08/26 08:23


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
     
At 05:28 PM 8/25/97 -0500, you wrote:
>At 03:16 PM 8/25/97 -0600, Eric Gindrup wrote: 
>
>I agree, BUT, the whole point of the random block generation is so that 
>the clients that can't connect to the server can continue to work.  IE 
>they won't be able to connect to get those tardy blocks.  Random generation 
>is the only solution that I can see.
>
Perhaps the ID numbers of some already checked key block could be used. In 
one 
of the future versions of the client maybe something like this could be 
incorporated.
     
The ID of a key block would be hard coded into a client ex. 193239:30000000. 
Now this block has already been checked and is known not to contain the key. 
     
The information contained in this block would be a number representing the 
percentage of the totally checked keyspace. Say 15%        
     
Since the keys are distributed sequentially the client would know, when it 
ran out of keys and went into the random generating routine, to only generate 
     
keys for the remaining 85% of the keyspace.
     
I feel this would significantly reduce the number of duplicate key blocks 
generated. Of course as the key space gets more and more exhausted more and 
more duplicates would be generated.
     
Perhaps another piece of data that could be passed via another key id would 
be 
relatively large gaps in the checked key space (tardy blocks) which could be 
added to the free key space generation.
     
Another idea is to use the key id to automatically stop and deinstall the 
clients once the key is found.
     
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0 
Charset: noconv
     
iQA/AwUBNAJoZnB9PoA+E8CpEQJQlACfcYgPUdhBWA1HWv85F/GsjC9Rx1MAoOVf 
hTTzSlieWkjJsgt2QYm1rCG5
=Lua7
-----END PGP SIGNATURE-----
     
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
body.
     


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



More information about the rc5 mailing list