Slashdot Mirror
Domain: distributed.net
Stories and comments across the archive that link to distributed.net.
Comments · 607
-
I know where it is!
It's hooked up to one of the Distributed.net projects!
-
Stolen LaptopsI remember reading something awhile back about a few laptops being stolen. Turns out that both of the laptops ran the distributed.net client. The next time the laptops connected to the net, the blocks were uploaded and the IP address was logged.
Both of the computers were recovered.
It was posted on Slashdot awhile back, and here is a link to the original story.
On a note to the story, what's going to happen to the MI5 agent? I'm assuming that he will be quietly discharged, and a few months down the road he'll disappear. (That usually happens to clumsy government agents. heh.)
-- Give him Head? Be a Beacon?
-
Re:RC5?
Check the stats for Team IBM
Dunno if this cluster is being used in the effort, though. -
Shrink the Buffer Size
You're not the only one-- I'm running this on a fairly beefy box and it still takes a LONG time (as in several days) to complete a single work unit. In order for the daily stats to be useful, it seems like one ought to be able to finish more than one work unit per day.
It's my hope that this is what they mean by: we will have the opportunity to improve some other aspects of client operation. In particular, we plan to add more configurable checkpointing and a better display of progress in their announcement.
As to the speed of the whole search-- that would depend as much on the size of the search space as on the speed of the client. Clearly we are looking at a real small search space if it were 25% searched in only a few days.
I know they never counted my seven days' work since it's all still sitting in my buff-out.ogr file. I'm using the dnetc v2.8007-458-CTR-00020606 for Linux (Linux 2.2.12-20) client-- perhaps it's client-specific?
-
Re:Dead Horses, Beating ofYes, you're correct. It's very enlightening that this error existed in one of the few pieces of code which is not present in the public source. It's unfortunate that we're required to obscure the buffer-handling and network protocol aspects of the client for project integrity, and we'd very much prefer it not be that way. It's unlikely that this sort of error would have survived the scrutiny of public source.
For those hwo haven't read it, Jeff Lawson wrote a document which explains why there are still portions of the client which are necessarily closed-source. The link is easy to miss, so I'm assuming those who are raising the issue here on slashdot have simply missed it.
-
It is Open Source.
Look at http://www.distributed.net/source/. If you had visited the distributed.net site, you probably would have noticed the "Source" option in the lefthand menu bar. But, hey, it's easier to whine, yes?
--Matt
-
groceronline.com sucks!
Unfortunately I can't purchase the Dilberitos locally, so I decided to check out groceronline.com.
I ordered a couple of Dilberitos, the total of my order was US $5.18 . . . shipping was US $15.99!! How can they charge three times the cost of products being ordered and get away with it?
The Dilberitos are meatless, so they shouldn't have to be shipped overnight. Seems to me they're taking a percentage of the shipping costs as pure profit, an all too common practice for on-line retailers these days.
Geez!
Join distributed.net, the largest computer in the world!
-
Certainly easier than OGR.
Well this would certainly be easier than running the OGR project. All my boxes are chugging away and all I've done so far is just over 100 packets.
-
A bit of poetic justice
For once, the US Gov't's own stupid laws can work for us. If they'd intelligently removed the arbitrary 56-bit limit, then we'd have a much tougher beast to deal with. However, consider this:
The keyspace is only 2^56 in size - the same size as RC5-56. Remember, that algorithm that distributed.net killed a year or so ago? Now, Moore's Law (and Tom'sHardwareGuide) say that our collective computing power has increased by a few hundred percent since the start of that contest.
So, let's launch a new contest, then, except this time we'll have:
- More willing participants (you directly benefit from the results!)
- Much, much faster equipment
- A keyspace that is only 2^56/n, where n is the number of monitor vendors who've been issued unique keys.
In any case, it should only be a few months until we could have the decryption keyspace entirely mapped.
Now, is that sweet irony, or what? God bless our Congress!
-
Now that I've woken up.Situation: I have a home PC attached to acable modem that's always on (in my case, Seti - those who would prefer that I do distributed.net, sorry, but I've made my choice for my reasons.)
This PC happens to run windows (Yes. I know. I'm inherently evil and feeding the great satan. Just flame me and moderate me down for admitting it and get on with your lives.)
I installed a firewall (Zonelabs), mostly because it was free, and also because I decided that if I wasn't part of the problem yet, it was only a matter of time.Results: I was getting probed at an average of once every 20 minutes from a variety of locations. Urk! (Please note, my ip starts with a 24, which tends to indicate an @home or roadrunner cable modem service)
Side note: If you want to test your machine, go to Steve Gibson's SheildsUP!. It's a bit slow at the moment (and posting this ain't gonna make it faster). Personally I wish I had known about this site before this insanity started.
----- -
Semantic masturbation & utilityIvo from distributed.net made a more limited case of the following point: saying, "Nothing is proved by achieving it," you implicitly create an environment where people wander around talking about things rather than adding (albeit in some small way) to the total of human accomplishment. (Sort of like posting to Slashdot all day rather than doing productive tasks.
I agree with you that the folks at Project Lightbulb are doing more interesting things. Then again, I'm more interested in Open Source ("Free", whatever) Software than I am in number theory. (Although I think number theory is neat, and lots of fun.)
But the point needs to be made, and by someone other than our good man Ivo, that no one associated with the OGR project is wasting their time. Some people like numbers more than they like modular programs. At any rate, writing distributed computing programs is a lot different from running distributed computing projects.
#include high_horse.h
{
Why do people - myself included - think they can blithely dismiss a problem if they know how to classify it?
} -
Semantic masturbation & utilityIvo from distributed.net made a more limited case of the following point: saying, "Nothing is proved by achieving it," you implicitly create an environment where people wander around talking about things rather than adding (albeit in some small way) to the total of human accomplishment. (Sort of like posting to Slashdot all day rather than doing productive tasks.
I agree with you that the folks at Project Lightbulb are doing more interesting things. Then again, I'm more interested in Open Source ("Free", whatever) Software than I am in number theory. (Although I think number theory is neat, and lots of fun.)
But the point needs to be made, and by someone other than our good man Ivo, that no one associated with the OGR project is wasting their time. Some people like numbers more than they like modular programs. At any rate, writing distributed computing programs is a lot different from running distributed computing projects.
#include high_horse.h
{
Why do people - myself included - think they can blithely dismiss a problem if they know how to classify it?
} -
Re:Mathematical masturbationIf you read our mission statement, then you will see that distributed.net is all about having a big (if not the biggest) distributed penis. It's not about the projects we're running, but about how we can get these projects done, in other words, "how can we build that largest computer in the world." That's why, besides keycracking contests like RC5, DES and CSC, we now do mathematical projects, and there's still a number of possible (non keycracking) contests on our todo-list.
Ivo Janssen
ivo at distributed.net -
FAQ-o-matic
Take a look at d.net's new FAQ-o-matic that allows registered users to add a FAQ answer.
Hopefully there's somebody watching over these answers to make sure they're correct, but I think this is a pretty good idea. Maybe the LDP could look at doing something like this.
I just also want to add my two pennies and say thanks to everyone who has contributed to the LDP. It's not perfect, but it has saved my ass many times. Hopefully, one day I'll be clueful enough to add my own contribution. Documentation is a dirty, rotten, thankless job, but without it the best code in the world is useless. -
Bad link
The article is here http://linuxguiden.linpro.no/experience. php
Join the largest computer in the world!!
distributed.net -
Re:Tampering
> isn't there the potential for error due to screwed up computers or deliberate tampering with the client? Take a look at the following url which contains details about how distributed.net try to prevent tampering: http://www.distributed.net/ source/specs/opcodeauth.html
-
"Intimate knowledge of the target processor"
For those that haven't seen it, distributed.net's crypto-cracking client has multiple "cores", from which it selects the fastest one for a given processor.
I ran a comparison between three machines (MII@233MHz, K6-3@400MHz and Celeron@300MHz). Remombering that they're all x86 architecture machines, there's some huge variations:
core MII K63 Celeron
#0 175 569 354
#1 426 648 70
#2 359 617 841
#3 520 547 694
#4 374 602 693
#5 362 704 712
Notice that the largest is a ten-fold difference!
The point of this? Imagine what your run-time optimising compiler could do when it knows the exact charateristics of the chip it's running on, as opposed to those of the chips it might run on. I know this is an extreme case, but there can be significant differences. -
A little clarificationrc5 uses very little if any FPU. In fact x86 and PowerPC cpus are better for rc5 than MIPS. From The distributed.net RC5-64 FAQ
Why are Intel and PowerPC computers so much faster than other platforms?
Integral to the mathematics of the RC5 algorithm are 32-bit rotate operations. For whatever reason, the designers of the x86 and the PowerPC architectures decided to implement the rotate function as a hardware instruction. Many other CPUs do not have built-in hardware rotate instructions and must emulate the operation by (at the very least) two shifts and a logical OR. This handicap is why many non-Intel and non-PowerPC computers run RC5 slower than one might expect based on real-world benchmarks. It is also the main reason why the RC5 clients are a poor benchmark to use in determining the speed or performance of a particular CPU.
Why isn't my computer with an FPU faster than mycomputer without one?
RC5 involves a large number of integer additions, rotates and XORs. It doesn't require floating point calculations and won't, in general, benefit from them. There has been quite a lot of recent discussion on whether or not it might be possible to boost keyrates (on x86 architectures at least) by taking advantage of the fact that there are separate pipelines for integer and floating point instructions. (We leave it to the reader to figure out how to do floating-point XORs and rotates!)
Currently none of the Bovine clients attempt to make use of FPUs and we believe any use of the FPU will result in slower clients rather than faster ones. At least one bright person has suggested this is notnecessarily the case and indeed he may be right. If anyone can develop an RC5-64 core that takes advantage of the x86 FPU for an overall client speed boost we would be very interested in hearing from them! If you are interested in looking into it the x86 core code is available and can be downloaded from http://www.distributed.net/source/.
SGIs are indeed very nice for image processing, but that has as much to do with their memory model, graphics hardware, bus speed, and other architecture considerations as the CPU itself. Seti doesn't stress the memory nearly as much as real image processing does and obviously doesn't use graphics hardware so it isn't a good benchmark for real use either.
I don't think SGI is going to loose their grip on the high end of image processing any time soon, but the low end keeps getting better with faster memory busses, better graphics boards and of course faster CPUs. For many purposes, SGIs are a luxury that is increasingly hard to justify.
-- -
That's just it... It's all about security...You're exactly right that security and authentication are some of the most signifigant hurdles between the current state of distributed computing and the future we all envision where no cycles are ever wasted.
Jeff lawson has put together an excellent treatise on the subject, outlining the specific pitfalls and challenges we see in this area. Recommended reading if this subject interests you.
-
That's just it... It's all about security...You're exactly right that security and authentication are some of the most signifigant hurdles between the current state of distributed computing and the future we all envision where no cycles are ever wasted.
Jeff lawson has put together an excellent treatise on the subject, outlining the specific pitfalls and challenges we see in this area. Recommended reading if this subject interests you.
-
Meta clientYou mean like, say, VMWare? Hell, isn't a virtual machine the ultimate meta client? Running, of course, a streamlined Linux OS. A Java VM is another option. Both take performance hits.
I was brainstorming around this general idea a while ago. The general problems I came up with were:
- Security of the host system.
- Authentication of the client application.
- Criteria for determining "worthy" projects.
- Billing, accounting, or payment tie-ins.
First off, distributed computing is very successful in some closed environments -- POW (pile of workstation) clusters in campus environments are common. A friend at a New Zealand biotech firm distributes Linux boot floppies. At the end of the "work" day, their Windows boxes are rebooted with this floppy installed, a Linux machine springs into place, and a gene sequencing client starts munching away -- the real work day. Similar schemes are pretty common.
In a broader environment with less control the problem becomes tougher. The host machine needs to have some guarantee of security. The client should also be reasonably secure and non-spoofable. There needs to be authentication.
In order to select for worthy (or billable) projects, some sort of voting scheme needs to b e implemented. If this is based on dollars or bill-backs, the small size of the individual contributions, with per-month CPU rental rates rating < $20 for new equipment (essentially the lease cost for hardware) -- means that this is not a way to get rich.
Factor in latency, bandwidth, lossage, and storage factors. It's a complicated problem.
This isn't to say it's not addressable. Distributed Net appears to be actively researching several of these areas. It's quite possible that all that idle CPU time will one day be put to use. But not real soon now.
What part of "Gestalt" don't you understand?
-
Re:Isn't there *something* worthwhile?
How about OGR, the upcoming distributed.net project?
-
Re:Isn't there *something* worthwhile?
How about OGR, the upcoming distributed.net project?
-
I know I'm biased......but for me it's distributed.net all the way. I was with Seti this past Summer, but three things contributed to my "desertion":
The lack of timely upgrades for the client a la distributed.net
The lack of updates of fresh content on the website a la distributed.net
Network outages
"Recycling" of data - just a horrible waste of time
I'm happy to say I was with CSC since day one and I'm still happily cracking away on RC5.
There's a much stronger feeling of a "team effort" with distributed.net, and how can you help loving those cool little cow icons?
Seriously, two weeks ago I reinstalled the NT command line version of Seti (an ANCIENT client, but there hasn't been an update) on one of my machines and let it run all night...wouldn't you know it, it hung on sending and receivingg the data, and the stats I had (I identified myself with the same Email address I had previously used) never showed up. So I deleted it and went back to CSC.
Let's keep cracking on RC5! I can't wait for the OGR contest to start.
-
I know I'm biased......but for me it's distributed.net all the way. I was with Seti this past Summer, but three things contributed to my "desertion":
The lack of timely upgrades for the client a la distributed.net
The lack of updates of fresh content on the website a la distributed.net
Network outages
"Recycling" of data - just a horrible waste of time
I'm happy to say I was with CSC since day one and I'm still happily cracking away on RC5.
There's a much stronger feeling of a "team effort" with distributed.net, and how can you help loving those cool little cow icons?
Seriously, two weeks ago I reinstalled the NT command line version of Seti (an ANCIENT client, but there hasn't been an update) on one of my machines and let it run all night...wouldn't you know it, it hung on sending and receivingg the data, and the stats I had (I identified myself with the same Email address I had previously used) never showed up. So I deleted it and went back to CSC.
Let's keep cracking on RC5! I can't wait for the OGR contest to start.
-
I know I'm biased......but for me it's distributed.net all the way. I was with Seti this past Summer, but three things contributed to my "desertion":
The lack of timely upgrades for the client a la distributed.net
The lack of updates of fresh content on the website a la distributed.net
Network outages
"Recycling" of data - just a horrible waste of time
I'm happy to say I was with CSC since day one and I'm still happily cracking away on RC5.
There's a much stronger feeling of a "team effort" with distributed.net, and how can you help loving those cool little cow icons?
Seriously, two weeks ago I reinstalled the NT command line version of Seti (an ANCIENT client, but there hasn't been an update) on one of my machines and let it run all night...wouldn't you know it, it hung on sending and receivingg the data, and the stats I had (I identified myself with the same Email address I had previously used) never showed up. So I deleted it and went back to CSC.
Let's keep cracking on RC5! I can't wait for the OGR contest to start.
-
I know I'm biased......but for me it's distributed.net all the way. I was with Seti this past Summer, but three things contributed to my "desertion":
The lack of timely upgrades for the client a la distributed.net
The lack of updates of fresh content on the website a la distributed.net
Network outages
"Recycling" of data - just a horrible waste of time
I'm happy to say I was with CSC since day one and I'm still happily cracking away on RC5.
There's a much stronger feeling of a "team effort" with distributed.net, and how can you help loving those cool little cow icons?
Seriously, two weeks ago I reinstalled the NT command line version of Seti (an ANCIENT client, but there hasn't been an update) on one of my machines and let it run all night...wouldn't you know it, it hung on sending and receivingg the data, and the stats I had (I identified myself with the same Email address I had previously used) never showed up. So I deleted it and went back to CSC.
Let's keep cracking on RC5! I can't wait for the OGR contest to start.
-
I know I'm biased......but for me it's distributed.net all the way. I was with Seti this past Summer, but three things contributed to my "desertion":
The lack of timely upgrades for the client a la distributed.net
The lack of updates of fresh content on the website a la distributed.net
Network outages
"Recycling" of data - just a horrible waste of time
I'm happy to say I was with CSC since day one and I'm still happily cracking away on RC5.
There's a much stronger feeling of a "team effort" with distributed.net, and how can you help loving those cool little cow icons?
Seriously, two weeks ago I reinstalled the NT command line version of Seti (an ANCIENT client, but there hasn't been an update) on one of my machines and let it run all night...wouldn't you know it, it hung on sending and receivingg the data, and the stats I had (I identified myself with the same Email address I had previously used) never showed up. So I deleted it and went back to CSC.
Let's keep cracking on RC5! I can't wait for the OGR contest to start.
-
Re:Mac OS client
Hi. I'm speaking here as a representative of the Mac coding team for distributed.net.
You're basically right on MacCSC. We're not wonderfully happy with its performance, but it does get the job done. The coders were extremely busy getting the Mac client to exist, and by the time it was stable and usable, CSC was almost over - G4 core optimization would have been next to futile. (Don't interpret me as making excuses; just explaining.)
RC5 performance, on the other hand, is mind-numbingly cool.
The lagging on 68k machines is due to timing issues; they're on the shor t list of Stuff To Fix.
We agree wholehartedly with the philosophy of release early, release often and adhere to it wherever possible. (I'm actually building a new client for seeding to our beta testers in the background as I write this.)
You aren't rambling offtopic at all - after all, this is slashdot.
-
Re:Mac OS client
Hi. I'm speaking here as a representative of the Mac coding team for distributed.net.
You're basically right on MacCSC. We're not wonderfully happy with its performance, but it does get the job done. The coders were extremely busy getting the Mac client to exist, and by the time it was stable and usable, CSC was almost over - G4 core optimization would have been next to futile. (Don't interpret me as making excuses; just explaining.)
RC5 performance, on the other hand, is mind-numbingly cool.
The lagging on 68k machines is due to timing issues; they're on the shor t list of Stuff To Fix.
We agree wholehartedly with the philosophy of release early, release often and adhere to it wherever possible. (I'm actually building a new client for seeding to our beta testers in the background as I write this.)
You aren't rambling offtopic at all - after all, this is slashdot.
-
Nugget's .plan
I just though I'd repost Nugget's
First, yes we do know who won, but we haven't been able to contact him so we're not releasing his name or information. We've got a good email address for him so contacting him will not be a problem. (I'm still going to try for the traditional phone call, first)
The winner was not on a team, and lives in the United States. Beyond that, I'd rather wait until we've made contact before more information is released.
OGR's next. We're going to do our best to make you guys happy... keep your eye out for future announcements!
-
he's in the US, not on a team.
As seen in http://n0cgi.distributed.net/cgi/dnet-finger.cgi?
u ser=nugget, he was not on a team, and lives in the US. -
Good job everybody!
I'm proud to have contributed to CSC since day one and I can't wait for OGR to start up!
-
Good job everybody!
I'm proud to have contributed to CSC since day one and I can't wait for OGR to start up!
-
Re:what about...
How's RC-5 doing?
Here's the stats:
http://www.distributed.net/statistics/
and...
http://www.distributed.net/statistics/
Scroll down a bit to get to RC-5.
-
Re:what about...
How's RC-5 doing?
Here's the stats:
http://www.distributed.net/statistics/
and...
http://www.distributed.net/statistics/
Scroll down a bit to get to RC-5.
-
Re:any good?
There are other project coming, such as the OGR project. It has nothing to do with encryption.
-
Re:SMP not what it's cracked up to be..
Well, at least Linux SMP doubles my keyrate for the distributed.net client. That's what really counts...
-
Re:I've given up on distributed.net
That was the last straw. That's a serious problem since 2 of the email addresses on my team aren't valid anymore so we can't rejoin that email address to the team.
Tried mailing their help-service to ask for the passwords for those addresses? I had a problem with two old inaccessible emails and they helped me out very quickly. I think they're doing a great job, considering the number of people out there who try and screw with the stats and break things.
Keep up the good work... Moo! -
open source dnet and Quake
> We've seen this before, actually, and it's still in the process of being dealt with; the release of the Quake source to the hungry open source world.
I know this is slightly offtopic, but a week ago when I read Jeff "Bovine Lawson's
It seems that both distributed key cracking and distributed Quake playing
-
open source dnet and Quake
> We've seen this before, actually, and it's still in the process of being dealt with; the release of the Quake source to the hungry open source world.
I know this is slightly offtopic, but a week ago when I read Jeff "Bovine Lawson's
It seems that both distributed key cracking and distributed Quake playing
-
Re:Yeah, I know it's a troll.Unfortunately, we've reviewed the proxy codebase and there is very little useful code in it that can be usefully disseminated without weakening the [non]-security of our data protocol. These are the same problems that prevent us from releasing source to all parts of the client (we've released most all of the non-network parts of the client at source already).
Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disasemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such.
We understand the problems that are preventing us from becoming fully open source and are working to solve them. We have already done a lot of research work in this area and are working towards an eventual solution that can be fully open source. The data re-verification introduced in CSC is part of this! You can check out some of our work in this area at opcodeauth
-
Re:Yeah, I know it's a troll.Unfortunately, we've reviewed the proxy codebase and there is very little useful code in it that can be usefully disseminated without weakening the [non]-security of our data protocol. These are the same problems that prevent us from releasing source to all parts of the client (we've released most all of the non-network parts of the client at source already).
Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disasemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such.
We understand the problems that are preventing us from becoming fully open source and are working to solve them. We have already done a lot of research work in this area and are working towards an eventual solution that can be fully open source. The data re-verification introduced in CSC is part of this! You can check out some of our work in this area at opcodeauth
-
100% -- Retesting blocks
While the main article does do a good job of saying that we as D.net'ers have to re-do about 25% of the keyspace, it does not cover the ending editors comment as to why we reached 100%. The real reason that D.net reached 100% is that we re-test somewhere around 10% of the blocks. This can be found in one of the portions of This Document, dBaker's plan. I hope this clears up any confusion as the two topics are related, but not the same.
J. Marvin -
More than one problem
There is actually more than one problem with CSC, which is causing it to go over 100%
First: dbaker (Daniel Baker), released an official anno uncement explaining that the same blocks were being issued to multiple clients, to attempt to detect cheaters.
Then dbaker released another anno uncement in his
Second: nugget (David McNett), released an announcement stating that there had been a problem with the keymaster generating invalid blocks, resulting in 25% of the keyspace being duplicated.
So, one remaining question is, are they still sending out ~10% 'verification blocks'? Or have they abandoned that to allow us to complete the project faster?
We have reached 112% due to verification blocks and could reach 140% due to 25% of the keyspace being corrupt. However, if 12% of the 25% new blocks are duplicated, then we could reach about 155%...
--
David Taylor
davidt-sd@xfiles.nildram.spam.co.uk
[To e-mail me: s/\.spam//] -
More than one problem
There is actually more than one problem with CSC, which is causing it to go over 100%
First: dbaker (Daniel Baker), released an official anno uncement explaining that the same blocks were being issued to multiple clients, to attempt to detect cheaters.
Then dbaker released another anno uncement in his
Second: nugget (David McNett), released an announcement stating that there had been a problem with the keymaster generating invalid blocks, resulting in 25% of the keyspace being duplicated.
So, one remaining question is, are they still sending out ~10% 'verification blocks'? Or have they abandoned that to allow us to complete the project faster?
We have reached 112% due to verification blocks and could reach 140% due to 25% of the keyspace being corrupt. However, if 12% of the 25% new blocks are duplicated, then we could reach about 155%...
--
David Taylor
davidt-sd@xfiles.nildram.spam.co.uk
[To e-mail me: s/\.spam//] -
More than one problem
There is actually more than one problem with CSC, which is causing it to go over 100%
First: dbaker (Daniel Baker), released an official anno uncement explaining that the same blocks were being issued to multiple clients, to attempt to detect cheaters.
Then dbaker released another anno uncement in his
Second: nugget (David McNett), released an announcement stating that there had been a problem with the keymaster generating invalid blocks, resulting in 25% of the keyspace being duplicated.
So, one remaining question is, are they still sending out ~10% 'verification blocks'? Or have they abandoned that to allow us to complete the project faster?
We have reached 112% due to verification blocks and could reach 140% due to 25% of the keyspace being corrupt. However, if 12% of the 25% new blocks are duplicated, then we could reach about 155%...
--
David Taylor
davidt-sd@xfiles.nildram.spam.co.uk
[To e-mail me: s/\.spam//] -
More than one problem
There is actually more than one problem with CSC, which is causing it to go over 100%
First: dbaker (Daniel Baker), released an official anno uncement explaining that the same blocks were being issued to multiple clients, to attempt to detect cheaters.
Then dbaker released another anno uncement in his
Second: nugget (David McNett), released an announcement stating that there had been a problem with the keymaster generating invalid blocks, resulting in 25% of the keyspace being duplicated.
So, one remaining question is, are they still sending out ~10% 'verification blocks'? Or have they abandoned that to allow us to complete the project faster?
We have reached 112% due to verification blocks and could reach 140% due to 25% of the keyspace being corrupt. However, if 12% of the 25% new blocks are duplicated, then we could reach about 155%...
--
David Taylor
davidt-sd@xfiles.nildram.spam.co.uk
[To e-mail me: s/\.spam//] -
Re:Accuracy in reporting!
I agree with you. reported this on the 3rd, here. While it's a bit of a "setback, it's still fun to crack keys at this rate. I am glad they finally adjusted the visible keyrate as well. Go D.Net!
-
I hate to say this, but...I think I've finally had it with distributed.net.
Anyone who's been following their
Wait--did I say this was the latest in their string of fuckups? Well guess what--as several hours had passed without a new bug report coming out of distributed.net, wouldn't you know it, now it turns out that they haven't actually completed 91% of the CSC project after all.
Yep, you read that correctly. Oh, but don't worry--it's not a bug, it's a feature. For those of you who won't take the time to click on the last link, here's how dbaker's latest
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...
He goes on to describe the fact that they've implemented redundancy checking to weed out hacked clients with the CSC project--a very good if a bit overdue move (although perhaps they could have disclosed this earlier?)--and that they've decided to give everyone full credit for all their blocks, even redundant ones--also a good idea--and so therefore there's obviously absolutely no way that they could avoid the actual keyspace being more than 100% of the reported "keyspace". Obviously. And this was the plan all along. Which is why they even wrote up not one but two new scripts which (falsely) calculate that the "keyspace" will be exhausted in only 2 days now. Obviously.
And of course it's perfectly fine that they just hoped that the project would get solved before it his 100%, so that they wouldn't have to inform their users that they've implemented redundancy checking. And no, they're not going to tell us how many percents are actually in the keyspace (105%? 110%?), or how many days it will actually take before we check all the keys and get to find out if they've somehow managed to fuck up yet again. Why should we be entitled to know silly information like that??
Meanwhile, dcypher.net has sprung up, and, in only a couple months, and with what certainly seems to be fewer people working for them than distributed.net has debugging their database they've:
come out with a CSC client which is 250% faster than distributed (on x86, at least).
Yes, that's 2.5 times as fast.
had stats which (gasp!) don't break or have new bugs in them every couple days and (gasp!) don't have a 2 hour scheduled downtime to update every night and even (gasp!) update in real time, almost like real databases do!
started the Gamma Flux project which, while not personally my cup of tea, is certainly the first distributed computing project which is actually useful (it helps calculate ideal containment solutions for nuclear waste).
promised to pass on the entire share of the CSC winnings to the person who wins, as opposed to distributed.net's 20% (10% if you join a team).
But what finally pissed me off the most was reading this post earlier in this thread from Decibel at distributed.net, in response to an admittedly pretty hostile post from Armin Lenz at dcypher.net, in which he has the gall to imply that dcypher shouldn't have done CSC at all because distributed had "announced" that they intended to work on it soon after the contest was announced, way back in May. Of course, Decibel doesn't mention the fact that they didn't launch the project until November 17, 2 weeks *after* dcypher.net, and only then with a broken client (yes, a brute force program that's 2.5 times slower than it should be is certainly broken), and that they haven't even *released* a finished client for the Mac!
And furthermore, he doesn't even understand that making the argument that "we announced first" isn't likely to garner too much respect at
And despite all that, he still says "we did CSC because it was relatively easy to add". Well I'd hate to see how badly they can screw up a project that's a little "hard".
I'm hoping I won't get the chance with OGR. Despite everything, I think OGR is a pretty cool project, and I just might be persuaded to stick with distributed.net if they (finally) come out with their OGR client, and it works, and isn't orders of magnitude slower than competing clients, and they fix their stats and get their act together. I suppose in the end I was always a sucker for the moo.
But distributed has a lot of lost trust to earn back.