[rc5] Random keyblocks
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
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: [rc5] Random keyblocks
Author: <rc5 at llamas.net> at SMTP
Date: 1997/08/26 08:23
-----BEGIN PGP SIGNED MESSAGE-----
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
of the future versions of the client maybe something like this could be
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
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
-----END PGP SIGNATURE-----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5