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

"Dan Oetting" <[email protected]> writes:
> Do you have a magic ability to out guess a random number generator?

Nope. Nor was the key generation source publically released, or the
system identified that it was run on. For all I know it was an older
unix box with a flawed rand function. Or that the default seed function
was used, with some predicable range or number of iterations that would
give a clue about distributions in the pseudo random sequence.

I have developed a preference for run length searching from other 
efforts which were based on human originated keys, since the ascii
text and key generation algorithms tend to perserve the non-random
nature of the text originally entered. That perference, might well
not make sense here, IF the random number generator used was truely
verifiably random.

> If there are multiple groups searching a large key space the space 
> should be divided into several large blocks and allow each group to 
> pick the block they will process next. It won't make any difference in 
> finding the winning key but it will prevent groups from blaming their 
> failure on someone else's pick. To prevent the groups failure being 
> blamed on the individual that picked the groups block each group will 
> probably use a random event to pick the block anyway.

Or implement a simple database of which keys have been searched, and how
using a redundant 3 or 4 deep 256 way tree in peer to peer mode with
network centric "geographic" tiers based on routing distance/topology.
With 150GB disks, it's not that expensive to maintain a few hundred
megabyte flat ascii file which is appended to by update messages from
local peers, and periodically sorted, uniq'd, and updates propagated
back out to peers.

It takes a pretty small DNS server hack to setup the initial contact
points, and modest effort to establish a redundant interconnection graph,
everything else can be cron driven perl/shell scripts.

> With projects handling 64 bits at a time that leaves 8 bits or 256 
> blocks for projects to pick from. Coordination of these assignments can 
> easily be handled by the projects publicly declaring which blocks 
> they've done, the block they are currently processing and the next 
> block they plan to work.

Why so coarse when a modest sized file allows several orders better
granularity?

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