Slashdot Mirror
Distributed.net Does CSC
The fine folks over at Distributed.net have appraised me of the fact that the long awaited CSC clients have been rolled out, as of a few hours ago. The full details went out on the mailing list recently regarding CSC and the new clients. Upgrade your clients, because they'll start serving keys in just a couple hours, and we can keep Team Slashdot in first place.
Check out George Woltman's links to distributed computing projects. This is not a comprehensive list, but includes most of the famous math/science related projects out there.
*groan* distributed.net has been running closed clients for awhile now. What I wouldn't give to know what makes those things tick. Well, time for a shameless plug... a friend of mine (and myself!) are working on a program that has some rather, ummm, interesting features. Namely it's distributed processing (hence the post under this thread!). What makes it cool is that a) we're releasing it under GPL, and b) has never been done before.
You see, my friend has thrown some genetic programming together with some math syntax checking / validation and created a novel program that can reverse-engineer algorithms. You give it the inputs you fed the "black box" and the output(s) it produced, and it divines what algorithm was used to do it. You can immediately see the benefits here. So I thought I'd plug it - it's a helluva lot more flexible than distributed.net (anybody can run a server - you got the source!), it's free, and it may be one of the first so-called 'software patents' to be licensed under GPL (as soon as I have some spare $$$, I might just do that too!). Oh yes... did I mention we're cooking some algorithms right now that'll hopefully let you find primes on a linear timescale instead of exponential? *evil grin* Noooo Mr. NSA... that's not *my* algorithm.... =)
If anybody's interested in pitching in, we could use a few extra hands getting the code all nice and prrrty and out into the hands of fellow slashdotters. =) mail me!
--
As of the time of this post (04:00UTC), we're just about to hit 200Mkey/second. We've completed a little over .007% of the keyspace. Although this seems very slow, it's an amazing start for a project with clients that we just released. At this point, we've distributed thousands of clients, but most won't report back until they've completed ten blocks. I expect the rate to have a huge increase in the next few hours as clients start submitting their first blocks.
Daniel
--
Daniel Baker - dbaker@cuckoo.com - dbaker@distributed.net
Feel free to hop on over and check it out.
Daniel
--
Daniel Baker - dbaker@cuckoo.com - dbaker@distributed.net
If we have a full userbase switch, we expect a 100% exhaustion in ~1 to 2 months.
That said, of course, we wont be able to get a full userbase switch, but chances are that we wont have to search 100% keyspace either.
In a few days we will have a better estimate of course, because then we will know real keyrates.
Ivo
<grub> Reading
I've put a rate clock up for this contest. It refreshes every two minutes and is continually updated by the master keyserver. Stats don't get any more accurate than this...
I am somewhat disappointed that the folks running d.net continue to make the same mistakes repeatedly. First, and in my eyes worst, is the fact that they are not able to advertise their contests worth a damn. Take a look at their home page. The announcement of the CSC contest starting is after several paragraphs of numbing boredom, in the same typeface as everything else. Distributed.net needs to learn to use the H1 tag. If they want people to switch their clients, they need a big, flashing siren or something!
The second problem is one that I'm sure a slashdotter with more time than I have will cover more thoroughly here. In short, the clients need to be opened. If you must obfuscate the block authentication scheme, then you have no authentication scheme to speak of. The poor design of d.net client security has been demonstrated by multiple occassions of people faking results. One principle of security is that you should always assume that the attacker knows exactly how your security mechanism works. It would be great if d.net could overcome this problem and harness communal brainpower for testing, bugfixing, and enhancement. Think of open source as a distributed.net for brains :)
-jwb
It says on their page that the CS-Cipher supports 0 bit keys! Woo hoo, no bothersome password to remember! Someone should patent that!
...what do you mean plaintext is prior art?
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
I'm only going to comment on the first point, as you've brought up precisely what I am now responsible for at distributed.net.
You're absolutely right. And we're working to fix it.
We've finalized a redesign of our web site and are beginning a complete rewrite of nearly all of our web content. After the major pages are finished, we'll go to work on the documentation, which is very lacking, often in some extremely important areas. The site will have a new hierarchial structure, with simple URLs for news, help, and downloads. Deep information will be even more readily accessible for those diehards who want it.
The changes will be rolling out in stages over the next thirty days.
Come back to distributed.net in a month's time. I promise, you won't be disappointed.
No, actually you can stop chewing on that foot. Much of the client is still closed-source. Here are the reasons they give (on the same page linked from above):
Why is distributed.net still closed-source?
Although we are providing all of the code linked on this page for public perusal, it is still necessary to keep select portions of the codebase unavailable for general distribution. Indeed, this is an aspect of our operations that we would very much like to be able to eliminate. However, there are several motivating arguments against open-source development with the current clients:
Thankfully, they realize that client-side security is no security at all, and appear to be working on a server-side authentication method.
I admit, it would be very nice to have the complete code-- especially for people experimenting on bizarre high-end hardware. At one time I was very interested in building an HP-PA 2.0 version of the client, but alas the source was not to be had. I also had some PowerPC 620 system running AIX which could have been used-- note the distinct lack of any AIX clients this time.
Here's to hoping that either:
or...
The biggest selling point for most of my friends who allow me to install the rc5des client (now known as dnetc) on their machines has in the past been the funky little cow. WHERE'S MY COW!!!! I WANT MY COW!!!!! How am I supposed to tell people about the cute cow that cracks crypto if the COW ISN'T THERE??? sure - we got a funky little blue thing, but its not cute, not cuddly, and my girlfriend will hate it! Come on D.net, GIVE US THE COW!
Ok, first note that I am so far from being a lawyer that it's rather humorous. Oh, and also note that I didn't think of this idea myself; it came from this rather fascinating article in Salon a couple months back. (Yes, it made /. at the time, but only as an update to an article about a new Beowulf for running GP.) And, yes, this is very offtopic.
/. links to seem to be precisely the opposite.)
But basically, the idea is this:
1. A prerequisite for an idea to be patented is that it's not obvious, even to the best experts in the field. That is, there needs to be some flash of creativity involved--some something that no one else can be expected to think of. This is why patents are supposed to be in the public's best interest--better to have the ability to use the idea in a "limited" amount of time (currently 95 years and counting) than to potentially never have anyone else think of it again. In the case of a patent on an algorithm (which covers just about any software patent), it's not enough that the problem the patent solves be novel--indeed, it should be relatively obvious; what needs to contain that unique insight is the algorithm itself. (Yes, this is how it's supposed to work, even though just about all the absurd patents
2. A good genetic programming environment--like this one, if it becomes successful--will theoretically be able to come up with an algorithm that implements any "solution" one would feed into it. A great one would even find an *optimized* solution. (Indeed, in the Salon article, it talks about genetic programs which have produced algorithms or schematics identical to 21 existing patents, and one which even lead to the discovery of a new rule in quantum theory!)
3. A computer program, even one that implements genetic programming, is a mechanical process. It is entirely deterministic, and can be simulated by anyone, assuming they have the CPU resources (especially if the program's open source!). Thus, anything this program thinks up cannot possibly be "nonobvious"; a nonintelligent computer just came up with it.
4. Thus, any algorithm this program can duplicate is nonpatentable. It may even be that any old patent this program can duplicate without specific knowledge should be retroactively unpatented, since if it's "obvious" now, it had to have been obvious then; that is, if the machine is not true AI (which of course this isn't), then it's not intelligent always; it's not like it can be "intelligent by 1950's standards but not by today's".
So...an interesting strategy to fight evil software patents. And indeed, perhaps to fight all patents, although of course it's much less obvious how to get a computer to create a non-software process.
Of course, it'll prolly be a ways off before a genetically created algorithm nullifies a patent. Still, I wouldn't be surprised if some time surprisingly soon, the entire idea of patents is very substantially curtailed, if not eliminated, due to this sort of thing...
IANAC (I am not a coder :) ), but we havn't done any core optimizations in the current client. If we get a large portion of our users converting over, we probably won't have to either, since we could exhaust the entire keyspace in a matter of weeks. Assuming that's the case, we're much better off getting unoptimized clients out the door, rather than spending weeks working on hand tuned assembly language cores.
One of the interesting things that happens when you get a very large group of CPUs together is that you don't always need or want to be very effecient on the CPU level... it's more important to be effecient at the *network* level. In this case, we're trading off effeciency in CPU cycles for time. Another potential example is algorithms that do not parallelize well, ones that need lots of inter-process communication for example. It might be possible to modify these algorithms to remove some of the inter-process communications at the cost of increasing CPU power needed. This wouldn't make sense if you were running on a single power machine, but if you're using a wide-area distributed computing network, it could make a *lot* of sense.
Decibel
decibel@distributed.net
sorry, I'm 76 on the Slashdot seti team and I'm not giving up any cycles ;)
It's 10 PM. Do you know if you're un-American?