staff blogs

distributed.net staff keep (relatively) up-to-date logs of their activities in .plan files. These were traditionally available via finger, but we've put them on the web for easier consumption.

2000-01-07

dbaker [07-Jan-2000 @ 09:45]

Filed under: Uncategorized @ 09:45 +00:00

:: 07-Jan-2000 09:47 (Friday) ::

I’ve gotten a very large number of emails asking for clarification
on the distributed.net reissuing policy and for details about
the precise amount of blocks being reissued. I have been distributing
this form letter:

————————————————————————
Greetings!

Thanks for your email regarding my post[1] or about CSC being shown
as more than 100% complete on the statistics page[2].

It is perhaps a common misconception that each CSC work unit
completed is unique. With a short contest like CSC, we have
implemented special keymaster code to use complex tests to verify
the authenticity and validity of each work unit submitted. Malicious
users could conceivably run a tampered version of the distributed.net
client to gain an unfair advantage in statistics and rankings. In
order to test an experimental method of attempting to uncover and
disqualify these users, it was decided that certain CSC work units
would periodically reassigned work done by suspect users to random
clients to ensure that our work is not compromised. As an unfortunate
result, work is duplicated.

There is no question that this method of project security is
suboptimal. We are aware of the flaws of this method and are
working to develop a new generation of clients that can produce
secure and reliable results. Jeff Lawson, distributed.net project
leader, has written an explanation[3] of all of the considered
methods. Distributed.net users can expect to see one or more of
these methods utilized in future clients and contests.

The method used by the keymaster to decide which blocks should be
flagged for reissuing is fairly complex and varies depending on a
variety of factors. At this point in the contest, we generally
have been reissuing between 9.1% to 11.5% of received blocks.

It is distributed.net policy to give users credit for all legitimate
work completed, regardless of whether it’s virgin work or reassigned
work. Accordingly, the completed percentage showed on the statistics
server represents both virgin and reissued work units, so it’s
possible that we go beyond 105% completion.

Every key in the keyspace has an equal chance of being “the” key.
Statistically speaking, it was unlikely that we reached this far
in the keyspace without finding the success key. However, this is
no indication that we will not find the key. We are just as likely
to find the key as we ever were.

I apologize if I didn’t address your issue specifically. I receive
hundreds of messages a day, and that load is growing exponentially
as we get further and further beyond 100% in CSC. If you need
general distributed.net support, please contact help@distributed.net.
Otherwise, can you resubmit your message to me.

Thanks for your continued support. Good luck.

Daniel Baker
distributed.net project leader

[1] http://www.distributed.net/cgi-bin/dnet-finger.cgi?user=dbaker
[2] http://stats.distributed.net/csc/
[3] http://www.distributed.net/source/specs/opcodeauth.html
————————————————————————