[rc5] Tardy keyblocks

Richard Freeman rfreeman at netaxs.com
Tue Aug 26 16:16:27 EDT 1997

On Tue, 26 Aug 1997, Eric Gindrup wrote:

>         When the unchecked keyspace in tardy blocks exceeds the unchecked 
>      keyspace in unassigned blocks, it is more effective to check a tardy 
>      block than an unassigned block.
>         Assuming that half of an average tardy block is known to not 
>      contain the target key (else the effort would have terminated) then 
>      when the number of tardy blocks is greater than twice the number of 
>      unassigned blocks, it is more logical to work on a tardy block than on 
>      an unassigned one.
>             -- Eric Gindrup ! gindrup at Okway.okstate.edu

At this point I am starting to really hesitate to waste bandwidth here...
But this is a really flawed argument (unless somebody shows me some math
to the opposite).  Even if there were only one unassigned key, and a
billion tardys - there is still no advantage of checking a tardy over the
unassigned one.  I agree that in this case it is more likely that the real
key is in the tardy pool - but it is not more likely that an individual
key in the tardy pool is the correct key.

Again, on my other note, I believe that you missed the point.  I agree
that cacheing tardy keys is more effective than using random ones.
However, it is just as difficult to cache a tardy one as an unassigned
one.  Consequently, whatever number of tardy keys you would want cached
could be replaced with unassigned ones (by increaseing buffer size),
without penalty...  Of course the ideal solution is to cache all of the
keys, but that defeats the whole idea of the distributed project and isn't
very practical besides.

At this point, I don't think I want to keep rehashing the same arguments -
I believe that the current strategy employed by the developers is
statistically the best possible one - or equivalent to others that are
equally good.  Most of the suggestions put forth only reorder the work.
The only exception would be a mechanism to make random-keys more likely to
hit unused keyspace.  The cost-to-benefit ratio for this is unclear - as
ideally nobody hould be cracking random keys except as a last resort
anyway...  I think that the best idea is to simply drop this and save
everyone on the list some disk quota unless somebody really has a novel
idea that they've really thought out well...

Richard T. Freeman <rfreeman at netaxs.com> - finger for pgp key
3D CB AF BD FF E8 0B 10 4E 09 27 00 8D 27 E1 93 
http://www.netaxs.com/~rfreeman - ftp.netaxs.com/people/rfreeman

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

More information about the rc5 mailing list