Re: Notes... The case for an open client

> So now your algorithm searches all the unlikely keys first, and 
> searches the likely keys last, making it take longer (on average) to 
> find the correct key. Except you think it's the other way around. And 
> while you're searching the wrong keys, d.net has beaten you.

Or, because d.net's initial random choice and search algorithm was very
unlucky, they are doomed to not finding the key until the very last
block is searched.

I might also be equally unlucky and choose an equally poor starting point
and search sequence, and we both are doomed to finding the key as the
very last block searched.

That, happens to be much more unlikely, with each of us searching with
independent starting choices and search algorithms ... and one of us
getting lucky and stumbling on the key a decade or two before the other
would.

Now ... what I proposed was a method of sharing searched key spaces and
algorithms, along with an indication of how much of the space was searched.
For the first few decades it will not make a difference as the overlap can
simply be considered second checking the others work. It also means that
each team can proceed without having to recheck, as the other will over
time if the key isn't found.

We both independently have a 50/50 chance of finding the key in the first
half the key space.

Personally ... trusting any PC which operates in a non-temp, non-power
conditioned environment is senseless as those machines only crash about
a fraction of a percent of the time when they are corrupted by environmental
problems ... and if you look around you, they crash frequently. You don't
run mission critical applications on machines where you can not trust the
results with a high degree of certainty.

d.net is just as likely to get to the end of the keyspace because some
corrupted machine missed the key, but returned verified partial keys in
the same block.

Since you seem to demand that I accept your perfect view of how I should
accept d.net, consider I don't see d.net as a perfect solution either.

John
_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware