:: 29-Jan-2003 05:11 GMT (Wednesday) ::

Own a piece of distributed.net history! topanga.distributed.net is for sale!

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2305156572

:: 26-Sep-2002 21:25 GMT (Thursday) ::

Congratulations!

Getting back to business here, we are seeing a few known bugs surface with some
existing clients older than build 465, which was released in early 2001.

As many of you have noticed, we have shut down the rc564 contest on the key
servers, so clients are unable to fetch/flush blocks to them. As a result, this
bug may cause them to not shut down properly when there is no more work to do
in the available contests. We would like to request that everyone check on all
possible clients and either upgrade them to builds >= 465, or uninstall them.
Additionally, clients that are configured to use rc5 only should either be
enabled to also run ogr, or uninstalled.

In the coming weeks, distributed.net will be releasing some new clients
and exciting new projects, so look forward to that and keep watching
www.distributed.net for more news and software downloads.

Thanks again for your support, everyone. RC5-64 was an incredible effort.

Cheers.

:: 12-Apr-2002 00:12 GMT (Friday) ::

Greetings, folks.

The master server will be offline for much of tonight and tomorrow morning
while it is couriered by FedEx Express to one of our new colo facilities.

I appreciate all the colo offers that I have received. I am splitting up our
network a bit and this is just one of our new homes. For those of you that have
offered space and haven’t heard back from me, I apologize for the delay. Moving
the master has been priority one and then I will work on moving the rest of the
equipment. I’m still interested in the offers that I received and plan to make
use of at least one, if not two, of them.

I currently have no plan to bring up a secondary master during the down time .
As a result, the proxy network will back up a bit and stats will be delayed We.
will catch up the network and the stats server within a day or so .

The master will be taken down at approximately 20:00CDT (01:00UTC) to prepare
it for shipment. Unfortunately, in AUS, the last FedEx Express drop-off time is
at 21:00CDT. We expect the equipment to be back online at the new colo facility
by about 15:00EDT (19:00UTC) That ultimately leaves us with about 18 hours of
down time.

This should be the new permanent home of the master server for many years to
come. Thanks to everyone who has contributed to pulling this off.

Cheers.

:: 01-Jul-2001 22:40 (Sunday) ::

I’m pleased to announce the installation and implementation of our brand
new Dell Poweredge 2550 master server. This new server is a dual processor
PIII-1GHz machine with 1GB of ram, 70GB RAID-5 SCSI disk, and redundant
power supplies.

The distributed.net master server is the head project server for OGR and
RC5. It handles the creation of all new work, processing of completed
work, logging, and various other operational tasks.

This new capacity and processing power will allow faster processing of
work, more reliable proxy network functionality, and additional log storage.

Jeff (bovine) and I completed the process of transitioning to the new
server 3am EDT and it has been working flawlessly since then.

Thanks to everyone for their gracious financial support that has allowed
us to continue to expand our network infrastructure.

:: 27-May-2000 08:25 (Saturday) ::

Moo.

It’s been a long while since I’ve made a planman updates, so I wanted to
make a post and attempt to get back in the habit of communicating
effectively.

I have very little new to report. For the first half of 2000, my consulting
business and non-computer-work aspects of my life have occupied most of
my time. Accordingly, little time has been left for significant
distributed.net projects. Regardless, I’ve been maintaining existing
services and continuing to handle day-to-day issues.

Yesterday evening marked the completion of a long outstanding project and
one of the first steps in replacing the ancient nodezero server. I
completed setting up a second web server and changed “www.distributed.net”
to be a round-robin between two of our servers. There are still a couple
minor kinks that we’re working out, but it will be flawless in no time.

I plan to finish up the new nodezero next week and make significant progress
towards replacing the old one shortly. I also need to catch up on the
keymaster log archiving. My work is cut out nicely for me. _]:8)

I’ll keep busy. Expect more news shortly.

-dbaker

:: 16-Jan-2000 07:17 (Sunday) ::

We won, guys.

See http://www.distributed.net/pressroom/dbaker-csc.html for more information.

Thanks for all your support.

Daniel

:: 15-Jan-2000 08:13 (Saturday) ::

Re: http://n0cgi.distributed.net/cgi/planarc.cgi?user=nugget&plan=2000-01-14.22:01

Yep, and I didn’t find any fake rocks around the keymaster. Hrm, pout.

:: 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
————————————————————————

:: 03-Jan-2000 08:47 (Monday) ::

As we near the 100% mark of CSC keyspace completion, I think it’s
time to explain what that CSC statistics mean, and how they are
determined.

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 to suspect users and random clients
to ensure that our work is not compromised. As an unfortunate
result, work is duplicated.

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 well beyond 100% completion.

Please remember that from the viewpoint of the network, submitting
duplicated work units is different from submitting blocks that have
been redistributed for secondary revalidation. Duplicated work is
defined as either re-uploading the same results or uploading stale
blocks that have already been recycled and redistributed. Meanwhile,
work units that have been redistributed for reverification will
have different sequence numbers and are credited as distinct pieces
of work. Please keep this information in mind when parsing our
statistics.

Thanks.

Daniel “dbaker” Baker and Jeff “bovine” Lawson
distributed.net project leaders