Jan. 12th, 3:33 pm:
Success! The answer is 333373190151749761757285479. Cool huh? =:-)
Our submission is here.
(NB: The number of iterations was 29562356154289, not 24249418904337.
I just got it wrong because I'm a bone-head).
You can stop your ECCp-89 programs running, and if you would like to work on ECC2-89, head over here.
Jan. 9th, 3pm:
Put a description of what our
pseudo-random iteration is, of which points are considered
distinguished, and of the format for sending them in. Our intention
is that with this information, others can write client programs and
work with us.
Dec. 31th, 5pm:
Put ecdlp-89.c version 1.02 on the Web site. It's slightly faster
so upgrade if you are in the mood but don't worry about it otherwise!
There is now a list of us and some timing blurb.
Dec. 30th, 5pm:
Put ecdlp-89.c version 1.01 on the Web site. It's slightly faster
so upgrade if you are in the mood but don't worry about it otherwise!
Dec. 29th, 5pm:
Wrote a bit of an explanation of the calculation.
Dec. 22nd, 4pm:
Did some stats counting distinguished points:
counter of points so far (with duplicate reports removed),
daily.rate since the start (includes duplicates),
hourly.rate for the last 24 hours (includes duplicates).
We need about 30000 points!
Dec. 19th, 10pm:
Start, call for volunteers sent out.
Dec. 18th:
Initial testing by Rob and British Telecom guys.
We've got some awesome machines and are capable of solving big problems if a large enough percentage of us are mobilised.
You may be aware that the first two problems in the Certicom ECC challenge were broken recently by a team of us using Alphas running Linux and Digital Unix.
You can read about the contest and our first two solutions at:
http://www.certicom.com/chal/contents.htm
http://www.certicom.com/first.htm
http://www.certicom.com/second.htm
Now we're moving on to ECCp-89 which will require about 1000 days CPU time at 500Mhz. With the same number of machines as before, this would take two months elapsed time but we're hoping to mobilise more people and keep the time down to a few weeks...
So why don't you grab the source code from:
http://pauillac.inria.fr/~harley/ecdl2/
compile it, and leave it running over your Christmas holiday?
30 trillion elliptic curve operations, here we come!
Merry Christmas,
-- Rob.
PS: Constructive comments on the code are very welcome.
* Get your hands on an Alpha running Linux or Digital Unix or NetBSD (the guys at B.T. have a VMS version running which will be available soon).
* mkdir /tmp/ecdl
* cd /tmp/ecdl
* Download ecdlp-89.c.gz from:
http://pauillac.inria.fr/~harley/ecdl2/
* Decompress it:
gunzip ecdlp-89.c.gz
* Compile with something like:
gcc -O4 ecdlp-89.c -o ecdl -DFROM=somebody@somewhere
or:
cc -O5 -tune host -std1 ecdlp-89.c -o ecdl -DFROM=somebody@somewhere
replacing "somebody@somewhere" with your email address, unless you prefer to remain anonymous, and appending one of the following flags:
If your machine is permanently connected to the Net:
-DTO=ecdl@pauillac.inria.fr
If it is connected but email to INRIA bounces, try this instead:
-DTO=robert@vlsi.cs.caltech.edu
If it is not connected, or email won't get through, use batch mode:
-DBATCH
* Run:
nice +10 ./ecdl > log &
That's it!
Both the default and batch modes output two lines like this:
ECCp-89 s 0000...ff3c [etc] v 0a6e...d084 RobsECDL 100 somebody@somewhere
Total iterations = 1683408480 at 344010/sec
to stdout (i.e., the log file) every few hours. The default mode also does popen("/usr/sbin/sendmail ...") to report the line back to base.
In batch mode, you have to do a bit of work transferring the lines manually. That could be by dialling in, or by carrying a floppy disc over to a Net-connected machine or whatever.
You should send the output once per day or every couple of days, by email to ecdl@nospam.pauillac.inria.fr, from a machine with ptr and mx DNS records. If that bounces use robert@nospam.vlsi.cs.caltech.edu instead. Note that the mail is processed automatically. To contact a human (me, actually :) use Robert.Harley@nospam.inria.fr. Remove the "nospam." of course.
It can't hurt to do this even in default mode, or to send things twice. In doubt, err on the safe side!
Merci beaucoup, Rob.
* If you run into any problems, please let me know so we can fix them. It's quite possible that I've done something stupid and if you don't tell me I'll never find out!
* If you compile on Digital Unix with -non_shared and run on Linux then use batch mode, since otherwise the compiled program will look for /sbin/sh whereas Linux has /bin/sh instead.
* If the default (non-batch) mode fails to open a pipe to sendmail, it outputs "Warning: couldn't pipe to sendmail, send by hand!" to the log file. If closing the pipe returns status other than EX_OK, it outputs "Warning: sendmail returned status xxx". If these happen a lot, you should switch to batch mode.