[rc5] Tardy keyblocks

Richard Freeman rfreeman at netaxs.com
Tue Aug 26 14:29:51 EDT 1997

I just wanted to try to step back and take a look at all these arguments
about tardy blocks.  I believe that we can all agree with two points:

1. A tardy block is more likely to contain a solution than a random one
once a sufficient period of time passes (we can debate about at what point
this is, but consider the point conceded for the purposes of this
argument).  Let us assume that at this point a tardy block is more likely
to have the solution than a random block...

2. A tardy blcok is less likely to contain a solution than an unassigned
block (various reasons have been given).

I don't think that anyone really argues these points.

The argument has been made that random blocks should not be checked
because tardy ones are available.  I submit that tardy blocks should not
be checked because unassigned ones are available.  Of course people say
"We won't prefer tardy blocks to unassigned ones, only to random ones..."

However, there is no mechanism by which a tardy block could be transmitted
to a client where it would not be equally effective to transmit an
unassigned one.  If there is no net connection, neither can be transmitted
(hence the need for random blocks), and if there is a connection, both can
be transmitted.  The idea of saving tardy blocks for periods of no
connection is no better than saving unassigned blocks for periods of no
connection.  The idea of giving clients some manner of better-directing
the generation of random-blocks does have merit.

Whatever resources are used in buffering tardy blocks can be used just as
effectively in buffering unassigned ones.  I submit that the latter is a
more effective strategy.  

Finally, the only reason that we check random blocks is because something
went wrong - for whatever reason, we did not plan on a computer not having
a net connection for some period of time, and the buffer ran out.  The
solution to this is not worrying about tardy keys, but simply increasing
the buffer-size.

If we run out of keys, then the tardy keys are obvious targets.  Until
then, we should give the computers that took them all the time possible to
give them a chance to crack them.  No sense in cracking a tardy key only
to have the original computer crack it again...

I don't mean to be stomping on anyones ideas.  I just don't think that
from a logical standpoint there is any reason whatsoever to worry about
them now - except for the developers to be prepared to assign them on a
moments notice once the keyspace is exhausted (we don't want people to
defect while the servers are being re-coded to handle tardy keys).

If anyone really thinks that there is a hole in this argument, then please
let me know. I've seen really complicated mathematical arguments about how
tardy keys are better than random ones, but I don't believe that this is
relevant - nobody argues that random keys are better than tardy ones -
only that there are instances where you simply have to fall back to
something, and random keys are the only alternative (because there is no
value in buffering a tardy key over an unassigned one...).

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