[plans] distributed.net .plan update

plans at nodezero.distributed.net plans at nodezero.distributed.net
Wed Jan 12 19:00:06 EST 2000

.plan updates in the last 24 hours: 
moose :: 12-Jan-2000 02:06 (Wednesday) ::

The following clients have been updated/added:

- Windows 95/98/NT [x86/Installer] v2.8005.454
- BSD/OS [2.x/3.x/4.x/x86/aout] v2.8005.454
- FreeBSD [ELF/x86/MT] v2.8005.454

See http://www.distributed.net/download/updates.html for updates by

See http://www.distributed.net/download/clients.html for updates by


2.8005.454  fix: all: infinite fetching from 'nowhere'.
            fix: all: undid that persistent log open change made in .451


moose :: 12-Jan-2000 04:01 (Wednesday) ::

The following clients have been updated/added:

- MacOS [PPC/OS7.5+] v2.8005.454
- MacOS [m68k/OS7.5+] v2.8005.454
- MacOS [fat/OS7.5+] v2.8005.454

See http://www.distributed.net/download/updates.html for updates by

See http://www.distributed.net/download/clients.html for updates by


moose :: 12-Jan-2000 04:01 (Wednesday) ::

The following clients have been updated/added:

- MacOS [PPC/OS7.5+] v2.8005.454
- MacOS [m68k/OS7.5+] v2.8005.454
- MacOS [fat/OS7.5+] v2.8005.454

See http://www.distributed.net/download/updates.html for updates by

See http://www.distributed.net/download/clients.html for updates by


vetere :: 11-Jan-2000 01:09 (Tuesday) ::

Now that -453 is out, and a number of the most troubling bugs have been
squashed, we've issued a press release concerning the Mac client. You
can find it here: 


For download URLs to the new clients, see Moose's plan. 

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


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 at distributed.net.
Otherwise, can you resubmit your message to me.

Thanks for your continued support.  Good luck.

Daniel Baker <dbaker at distributed.net>
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

decibel :: 07-Jan-2000 07:18 (Friday) ::

Ok, everything on CSC should be all set again, hopefully just
in time for us to announce that it's over tomorrow };8)

(NO, this does NOT mean we found the key yet!) }:8)

bovine :: 06-Jan-2000 12:55 (Thursday) ::

We've gotten a handful of questions recently from people who are
excited about the recent announcement about work verification.  I'd
just like to take this opportunity to point people to the existence of
an old document of mine that has been public for awhile that describes
many of the issues involved and some of the methods we had considered.

nugget :: 02-Jan-2000 01:43 (Sunday) ::

We tried to be clever, and it didn't work out...  We tried to recover
some of the team joins performed during the 27-Dec to 29-Dec and it
looks like our code accidently unjoined a few people from their teams.
The problem doesn't look too widespread, but it may have affected you.
If you notice that your blocks are not being properly assigned to your
team (you'd see this in the members list), please kindly rejoin your team.

If your team doesn't provide a member's listing, you can verify that
you're still properly joined to your team by editing your participant
information, which will show your current team affiliation.

Sorry for the mishap.

chrisb :: 22-Dec-1999 18:38 (Wednesday) ::

I've just uploaded a new x86/Solaris client, which has the MMX CSC core, as
well as being multithreaded (fixes bug #450). I also uploaded a v311 x86/
Solaris personal proxy, which is CSC compatible.

Hopefully they'll become available soon.

bwilson :: 15-Dec-1999 17:22 (Wednesday) ::

At long last the baby is here.  Ethan James Wilson was born at 12:40 a.m. Saturday, Dec 11 (06:40 Saturday UTC, for all
you stats freaks). He was 8 pounds, 13.5 ounces and 20 inches.  Tricia and Ethan both came home Monday, and we're trying to
figure out what "normal" means all over again.

As you know, we will be starting work on OGR soon.  OGR brings a whole mess of problems to what you know of stats today.  
When keymaster hands out an OGR node, there's no way of knowing how much work that node will require - it can even vary by
CPU. To give full credit for your work, stats will have to keep track of how much work you actually had to perform.
(You'd certainly like more credit for 10 nodes of 1000 effort than someone who did 10 nodes of 100 effort.)  It's also not
possible to say how much work we'll have to do at the project level, so concepts like "percent done" and "odds of finishing
today" are pretty meaningless.

On top of this, we're learning some things about managing multiple projects in a single database. Currently, a new project
means a new family of SQL tables, PHP scripts, a new import and a new stats run.  For our sanity, we'd like to reduce the
duplication as much as is reasonable.  I'm putting together some prototypes of options for the next generation of stats so we
can poke and prod them to see how well they work.  If you notice some drool on the stats database, that's probably because I'm
holding Ethan while typing.  I'll get it all mopped up before we do anything to the stats you know and love.

I'm also informally collecting ideas for ways we can rank individuals and teams across multiple projects.  In particular, we
want to allow participation in any open project to contribute to the overall ranking.  As it stands now, there's a lot of
motivation for teams to stick with RC5-64 to protect their ranking, instead of helping out with CSC.  Just think how fast we
could be demolishing CSC with a keyrate in the 80's instead of the 20's!

Happy cracking!

myshkin :: 06-Dec-1999 22:47 (Monday) ::

The glibc2.0, nomt linux-ppc client is on the FTP sites.

A glibc2.1 mt client will hopefully follow shortly, but I need to 
upgrade my build machine first. I won't be incorporating the AltiVec 
cores until binutils supports AltiVec.

ivo :: 18-Nov-1999 00:14 (Thursday) ::

Wow, it sure has been a long time since I updated this plan.
Seems CSC is rolling allright! That's why I took another look 
at fetch at distributed.net and flush at distributed.net.
They now accept CSC blocks to flush and if you want to fetch
CSC buffers add "contest=csc" to your request.

nitehawk :: 17-Nov-1999 20:54 (Wednesday) ::

Well... I've been idle for long enough now.  I'm currently in the
process of getting the csc stats pages together while nugget gets the
backend scripts together.  Assuming all goes well, we could have CSC
stats by tonite or tomorrow's stats run.

daa Ģ

sludwig :: 06-Oct-1999 22:06 (Wednesday) ::

The newest installer for the Win32 CLI client, that Bovine
mentioned in his recent .plan, has a few new additions to
help those of you that are use to the Win32 GUI.

This new installer gives you the option to install links
to the more common command line options; -config, -help,
and -shutdown on the Start Menu.  For those of you that
install the client hidden, you can opt to not install
*anything* to the Start Menu.

It also puts these links, actually short-cuts with the
options built into the shortcut, into the directory that
you install the client to.

This new installer also gives you the option to put the
client in the Startup Group along with the option to have
the client start from the runservices line, hidden.
The Startup Group addition lets you start the client
minimized to the systray, not unlike the old GUI.

I hope these additions to the CLI installer helps those of
you that are having a hard time adjusting from the Win32
GUI to the Win32 CLI.

Scott Ludwig

remi :: 03-Oct-1999 16:32 (Sunday) ::

Hi all,

As you may know, we have a glibc problem with x86 Linux clients. If
the client is statically linked with glibc 2.0, it can't resolve
host names under glibc 2.1. And vice-versa.
Previously, we had 'solved' the problem by providing two clients, one
for glibc 2.0 and another for glibc 2.1. This is confusing for most

I want you to beta-test another client. This v444 client was build
and linked against glibc 2.1.1 on a SuSE 6.2 system, but this time is
was dynamically linked. I think this should solve the problem, but I
need people to test this client to be sure.
I'm particularly interested in beta-testers on glibc *2.0*
systems. Tell me if it works on your machine or if it doesn't, but
please include as much details as you can in either case.

Here's the url : 
and the GnuPG signature :

Note to i386 & i486 users : You will see a slight drop in performance
because we can't link the 386/486 self-modifying core in a dynamic
client. If you want the best performance, you should stick with the
443 client.
We will continue to include this 386/486 self-modifying core in future
a.out and libc5 clients.

gregh :: 20-Sep-1999 05:57 (Monday) ::

Finally, some OGR news! An OGR test master is now operational. For the
latest news, see:


cdy :: 02-Sep-1999 14:26 (Thursday) ::

Distributed.Net rox.

alde :: 23-Aug-1999 15:12 (Monday) ::

Ok, I fixed the Athlon's spelling on the submit form, and so far have 2 

Operating System: DOS (MSDOS/PCDOS/etc.) -- 
CPU Type        : AMD K7 (Althion) -- 
CPU Speed       : 600 Mhz -- nomal
Client Running  : Bovine v2.7100 (RC5) -- 
Client Speed    : 2,011,659,59

Operating System: Linux -- 
CPU Type        : AMD K7 (Althion) -- <- Athlon!
CPU Speed       : 500 Mhz -- 
Client Running  : Bovine v2.7106 (RC5) -- 
Client Speed    : 1.517.000,00

I would put the 600 as an outlyer, but the 500 looks to be valid.

(I haven't seen one live to be a viable source of data on the Athlon.)


jfc :: 22-Jul-1999 02:04 (Thursday) ::

Here's to keep you updated on what I've been up to lately. I have been pretty
busy getting translated versions of the web site up online for our non English-
speaking users. Our team of translators has been stunningly efficient in
translating pages in many different languages, including Russian, French,
Dutch, German, and more to come, such as Danish, Italian, Spanish
and Portuguese. Many thanks go to them.

At first, the way things were handled is that users' browser language
preferences were taken into account to serve them the 'most suitable' version
of the web site. It soon enough proved to not be a very effective way of
offering multilingual pages. That's why as of yesterday, the translated pages
are only accessible via the links that are present at the top of each page.
Everything should now default back to English in any case.

Sorry about the temporary inconvenience that some of you may have experienced
over the past two weeks. Thanks. 

sampo :: 29-Jun-1999 23:42 (Tuesday) ::

update time again.  several bugs were found in the last release, and most are fixed.
try out the latest client (1.6.3b2) at the download locations below.  Anyone who
downloaded the previous beta is strongly advised to upgrade.  Keep the bug reports
coming.  thank you.

http://web.triton.net/sampo/rc5des.PPC.sit [251k stuffit 5.x format]
http://web.triton.net/sampo/rc5des.PPC.bin.gz [243k gzip'd macbinary]

davehart :: 28-Jun-1999 18:12 (Monday) ::

Banners submitted in the last 6 months have finally been processed
and moved into circulation.  For instructions on adding a d.net 
banner ad to your web site, check out 


To see all the banner ads currently in rotation on one glorious page,
and probably inflate your browser memory footprint to 20MB or so, see:


As always, your 400x40 .gif or .jpg banner ad submissions are welcome
via anonymous ftp to upload.distributed.net's incoming directory. 
Please upload a .txt file with your name and email address, so we
can give credit on /banners/.

Please accept my apologies for the delay in processing submitted banner
ads, the volunteer who previously handled this has been away from 
distributed.net and no one thought of it until it was mentioned
in #distributed channel on EFnet IRC.

Dave Hart

alex :: 27-Jun-1999 17:56 (Sunday) ::

No plans at the moment

pice :: 06-May-1999 04:24 (Thursday) ::

    As users of the newer (440+) win32cli client may have noticed, many of
the features that have been requested by users of this list have already
been implemented. Work has begun on a remote administration feature and we
would like some feedback on this, please send your suggestions by May 14th
to rc5 at lists.distributed.net. You can also check
http://www.distributed.net/~pice/console for current status.

    This program will actually be three programs,

        It will be change so that it can receive request for changing *some*
of its config info, among then we can have:
            block size
            network setting
            log options
            blocks processed
            overall keyrate
            <name your suggestion>
        One item will *not* be allowed to be changed:email, please do not

    2-node program
        It will act like a really to handle config info generated by the
console and sent to a client
        It will act like relays  to handle config info to be sent to the
client and no contest info like blocks.

    3-management console
        So that the user can check/change client configuration working like
a config info server

    How will it work ?

    The client will connect from time to time to one of the nodes and check
if there is a console requesting communication with it. If such a console is
found the config process is started. Clients connected all the time and
without any firewall problem can inform the node this status and just wait
until something arrives for it.
    Of course all this communication will be encrypted so that you cannot
request a client that is not yours to change any info!

peterd :: 19-Feb-1999 03:16 (Friday) ::

I'm working on the Mac client.  Right now I'm concentrating on optimizing
the scheduling code, including making it work with the next release of
the MacOS, and making the settings to control scheduling much easier
to use.  I also do the BeOS client builds.

peter :: 13-Feb-1999 22:26 (Saturday) ::

Statsbox2 is now installed and running in its new home, allowing 
Nugget to resume preparations for putting it into service.

grub :: 05-Feb-1999 17:29 (Friday) ::

watch this space
It'll be Insanely Great...

fordbr :: 17-Jan-1999 12:18 (Sunday) ::

Re-wrote S-box 3 and modified slightly S-Boxes 1, 2, 6 and 8 for

Should give a 4% speedup.

cyp :: 27-Dec-1998 02:48 (Sunday) ::

Well, not much is new code wise. I wrote a little snippet so that the win32
"cli" client minimizes to the task bar, and (also a "RuleR" suggestion) 
added long block benchmarking as a right-click option.

deathboy :: 04-Dec-1998 22:18 (Friday) ::

plan, what plan .. I have no plan!


blast :: 05-Oct-1998 22:28 (Monday) ::

Been working on fixing the -help "bug" that I've had in
my last trees, I think I nailed it now, not entirely sure, I'll have
to do some testing. Got the new 68k cores working a small
while back, they're awesome, hope I can release something soon.

Had a go with compiling the perproxy for AmigaOS. Let's just
say it doesn't compile yet and leave it at that. 
The AmigaOS specific parts are what they were in the 2.005 clients,
and those that remember those days also remember that I rewrote
a lot of AmigaOS code which made the client nicer (imho). Guess
I'll have to start moving code from the client tree (AmigaOS specific
code only of course) or rewriting those parts anew. I'll see what I'll
do. I'm working on it regardless...

My own domain is now fully operational and reverse name lookups
also work as they should now.

paulf :: 25-Sep-1998 14:47 (Friday) ::


tomn :: 25-Sep-1998 05:20 (Friday) ::

Yould Bay!

moose :: 12-Jan-2000 22:09 (Wednesday) ::

The following clients have been updated/added:

- Linux [x86/ELF/libc5/MT] v2.8005.454
- Linux [x86/ELF/glibc2.0/MT] v2.8005.454
- Linux [x86/ELF/glibc2.1/MT] v2.8005.454
- Linux [Sparc/ELF/glibc2/MT] v2.8005.454
- NetBSD [m68k] v2.8005.454
- OpenBSD [Sparc/aout] v2.8005.454

See http://www.distributed.net/download/updates.html for updates by

See http://www.distributed.net/download/clients.html for updates by

Happy Cracking!

moose :: 12-Jan-2000 22:09 (Wednesday) ::

The following clients have been updated/added:

- Linux [x86/ELF/libc5/MT] v2.8005.454
- Linux [x86/ELF/glibc2.0/MT] v2.8005.454
- Linux [x86/ELF/glibc2.1/MT] v2.8005.454
- Linux [Sparc/ELF/glibc2/MT] v2.8005.454
- NetBSD [m68k] v2.8005.454
- OpenBSD [Sparc/aout] v2.8005.454

See http://www.distributed.net/download/updates.html for updates by

See http://www.distributed.net/download/clients.html for updates by

Happy Cracking!

To unsubscribe, send 'unsubscribe plans' to majordomo at lists.distributed.net

More information about the plans mailing list