[rc5] What will happen
marcus at dfwmm.net
Sun Aug 3 18:54:39 EDT 1997
Michael Burman wrote:
> From: SMEarp at aol.com <SMEarp at aol.com>
> >It waits until the effort has run throught the entire keyspace, then goes
> >back and checks the unreported keys.
We're still a long way from here!
> This is so really slow machines that
> >take, say, 3 months to complete a block can still be part of the effort.
> 3 months. Uh. Lets say, with 1000Keys/sec 1 2^28 block is checked littlebit
> over 3vrk. Where can you find machine, that runs client with so slow speed?
> It could crack only 30Keys/sec [uh, C64?-)].
> There's no use for that slow machine.
Actually, there is quite a lot of use for that slow a cpu. Check
your VCR, microwave oven, telephone, cellphone, pay phone, alarm
clock, car radio, a/c thermostat, water sprinkler controller...
It doesn't really matter. It's the policy and there's no reason
to change it. It actually makes things quite a bit more compact
as far as the only need is to keep(long term) track of blocks
reported as checked. No worry about keeping track of what key
block has been issued, what is it's expiration time, and so forth.
As long as the algorithm for issuing keys is non-sequential, the
master server must log the keys that have been issued, but that
is all. No scanning the db for expired keys, no wasting of cpu
resources because it happens to be a slow one, or one that is
temporarily heavily loaded, or one that was shut down for
maintenance, or because of a crash, and so has its keyblock re-issued.
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5