<drwiii> Hi everyone, thanks for showing up today.17:01

I'd like to welcome you to the SlashNET forum with the Distributed.Net guys!

If you have a question you want asked, submit it to Questions like so: /msg Questions <question>

Now we've got quite a few guests that should be speaking today, so it'd be great if they could announce who they are right now and kind of give us a backgrounder on what they do.17:02
<Nugget> Hello, I'm David "nugget" McNett, co-founding board member and acting president of distributed.net. While I'm not the most useful of the d.net staff, I seem to speak fluent non-geek which puts me at the front of things from time to time.17:03
<BovineOne> I'm Jeff "bovine" Lawson and one of the original people that began the group that eventually became distributed.net. I did much of the original coding and develoment and I continue to oversee some of the development today.17:04
<sdodson> And mascott :)17:05
<drwiii> And here we go :)
<Questions> nard asks: How does the d.net admin, especially Nugget, feel about accomplishing a 5 year long project, and are they willing to dedicate another 5 or 10 years to d.net?
<Nugget> rc5-64 is certainly the most long-term project I've ever been involved in. 1757 days is a frightfully long time.17:07
<BovineOne> It's a great representation of the amount of power that can be assembled through distributed computing, and that's always been our primary goal--proving the viablity of large scale distributed computing.
<PeterDoubt> And as for the future, I think we've shown we're in it for the long haul. :)17:08
<Leto_> we've been getting quite a few new cool people on board in the last couple of years, too!
<BovineOne> Definitely we'd like to try to allow distributed.net to continue as long as we're able to do it, and as long as other people have interest in participating. We have no plans to end it anytime soon.17:09
<Nugget> Looking onward to rc5-72, which we're very motivated to offer as a choice of project to the participants, we all decided that we certainly didn't want the size and potential duration of a project to deter us from understaking the challenge.
<Questions> Lazy asks: Were you expecting a shorter time for completion ?
<Nugget> the bottom line is that completing a project that took 1700+ days adds to the accomplishment and sense of achievement, not detracts.17:10
<dbaker> The question might be better for the actual folks who run the clients and how long they can stay interested in a project. Clearly, there's no ending to the interest in RC5.

Clearly, everyone has seen that I thought that RC5-64 would have ended long ago. :)
<bwilson> Anything over 50% was statistically surprising.
<dbaker> (Famous quote: http://bash.org/?6699)
<BovineOne> When we began RC5-64, the estimated completion times were insanely huge. The fact that we got it done in much less time is noteworthy itself.17:11
<Questions> Lazy asks: How comes it took so much time between the key is found and the message of end (more than 2 months)17:12
<Nugget> there are two parts to this answer.

The first portion of the delay was entirely our fault, and we're quite embarassed by it.17:13

It simply took us a month to notice that the key had arrived. On the keymaster there is a success.log which, in past projects, sits at 0 bytes until the day the winning key arrives.

however, with the rc5-64 project there exists a buggy version of the client which generates false-positives. Consequently, the success.log became huge and was constantly growing.17:14
<bwilson> As luck would have it, the subspace we started with was one higher than the subspace where the solution was actually found. Luck of the draw, but we'll blame it on dbaker anyway.17:15
<Nugget> this caused us to disable the klaxons and pages that would normally accompany the winning key and we never seemed to replace the old code with newer code designed to accomodate the false positives.

and, frankly, after 1700 days the task of manually griping the success log for a real win just wasn't something that we did on a daily basis.
<BovineOne> The key arrived on Jul 14, and unfortunately the logs were last manually checked just a few days before on Jul 12 21:33 UTC17:16
<Nugget> the second aspect of the delay was simply the normal coordination with RSA Labs on when the victory would be announced. Press releases get drafted and reviewed and passed through legal.

the timing of the announcement is coordinated with other RSA Labs press releases, etc.17:17

The coordination took longer than usual this time, but not by much.

s/griping/groping/ :)17:18
<dbaker> although the constant groping did result in griping... :)
<Questions> nard asks: How will d.net spend the $6000 prize money?17:19
<bwilson> Bad timing contributed to the RSA part of the delay as well, since they were hip-deep in a conference which drew people away from our announcement.
<Decibel> we'll spend in on hay for the cows, of course! ;P17:20
<BovineOne> We occasionally need to upgrade and replace servers that we run our network on, and it'll go towards supporting those costs.
<Nugget> We are facing some potentially large legal and professional bills in the next few months as we once again face the irs for a permanent ruling on our 501(c)(3) tax-exempt status. 501(c)(3) is provisionally granted and all organizations must undergo a review to ensure they have lived up to the obligations before receiving that status permanently.17:21
<bwilson> Since these big checks only come in every few years, you can be sure we'll save it for something important.
<dbaker> Luckily, most of our networking resources are donated, so that avoids most of the considerable expense in operating such a massively large network.
<BovineOne> and although much of our bandwidth and colo space is donated, there is some that is not
<bwilson> We are quite grateful to our participants, who voted to give us the lion's share of the winnings, rather than one of the other charities we list.17:22
<Nugget> indeed17:23
<Questions> ootte_ asks: Will distributed.net stay non-profit or are there thoughts about selling cycles, etc. ?
<Nugget> distributed.net will always be a non-profit venture and feels strongly that there will always be a role for truly public-interest and volunteer-driven distributed computing projects.17:24
<Questions> Nutcase asks: What did it cost to run RC5-64 for these 5+ years?17:25
<dbaker> Many sleepless nights.17:26
<bwilson> It's worth noting that some of our participants can only participate on the condition they get no compensation.

If we paid our participants, we would stand to lose some of them.

Time with our families, in some cases.

These personal costs often outweigh the financial costs.17:27
<Leto_> nutcase: a couple of boxes on hardware, and like we said, most bandwidth and colo space is donated
<BovineOne> but it's difficult to put a price on the working on an exciting project that you enjoy doing as a hobby for enjoyment.
<Leto_> so it's really hard to say what it _would've_ costed if we had to pay for all that.17:28
<Decibel> It's rather difficult to put a number on just RC5 expenses. There has been financial outlay to keep our network running, but we have run 5 different projects in the time RC5-64 has existed.
<bwilson> Yes, if it wasn't rewarding, we wouldn't be here.
<Decibel> And as mentioned, the outlay of volunteer time far exceedes the hard dollars spent.

Also, there are costs associated just with running the organization, which don't directly relate to RC5 (or the other projects, for that matter).17:29
<BovineOne> yup, the physical hardware costs are of course just a small manifestation of the staff time and volunteer required to support it the project.
<Nugget> I'd like to take this opportunity to mention and thank some of the groups that have donated server space and bandwidth without which distributed.net would have a difficult time staying operational. Notably visi.com, nominum.com, and iquest.net.17:30
<dbaker> also ud.com, insync.net, neosoft.com, hfdirect.com, and of course, hmc.edu17:31
<Janacek> and slacker.com :)
<Nugget> naturally :)
<PeterDoubt> And...all of you. :)
<Janacek> not to mention the happy home of sb1 and 2, best.com :)17:32
<Questions> knightmare asks: what do you think about the fact that rc5-72 would take 256 times more time than rc5-64 (it's much, even if the network rate gets 10 times bigger)?
<Nugget> It's important to note that at our current rate we will complete rc5-72 in less time than our estimates were for completing rc5-64.17:33
<PeterDoubt> RC5-64 was 256 times bigger than RC5-56.
<Janacek> we could find it at <5% of the keyspace this time :)
<BovineOne> computer speeds are always increasing, so that greatly helps to reduce the time it will require.
<bwilson> If my calculations are correct, teams slashdot.org and slashnet.org contributed over 1% of the total work on this project

256 times more work does not mean 256 times as long working, after all.17:34
<BovineOne> If you believe Moore's law, computer speeds double very regularly.
<Nugget> at the core of this questions, though is the simple fact. If distributed computing isn't for tackling challenges which seem impossible, then what is it for?
<PeterDoubt> We were crazy to attempt RC5-64. We're still crazy.
<Janacek> we had around third of a million participants in rc5-64, only three times that to get to a million
<bwilson> As the saying goes, "if brute force won't solve your problem, you aren't using enough"17:35
<BovineOne> And of course, bringing in more of your friends to help run the client will also bring down the time required. :)
<Leto_> as long as you get permission from the owner of the boxes!
<Moonwick> And make sure they bring some macs. :)
<Questions> NevDull asks: Now that we have such a long-term RC5 project again, will the default project as shipped be for rc5-72 to have priority over OGR, unlike the recent clients which preferred OGR?
<bwilson> The client has default simply to make setup simpler for unsophisticated users.17:36
<BovineOne> our client actually doesn't prefer either by default. it actually rotates between all open contests, unless you tell it not to participate in one of them
<bwilson> It does us no good if a user installs the client and can't figure out how to get it started. It has to start somewhere.17:37
<Questions> CptVipeR asks: what was the size of the stats datebase in the end? and what was the spec of the stats machine?17:38
<BovineOne> it's probably best that people actually allow the client to work on all projects, instead of just one. otherwise we end up with the situation that we have now where a number of machines have gone idle because they were set to only run rc5.
<Decibel> The main table that contains all participant data is over 50 million rows. The database itself is around 9GB.17:39

that's for all contests we have stats on right now17:40
<Nugget> There's an additional 338,000 rows of rc5-56 data which is not online at the moment.
<Decibel> The machine itself is a quad Xeon PII 450MHz whith 2G of ram

it has 6 36G SCSI drives, arranged into a raid1 and raid517:41
<Questions> ShamusALT asks: are clients going to be developed for appliance systems like nokia phones, ps2's, dream casts?
<BovineOne> we actually have PlayStation2 client on our download page now17:42

but in general we've tried to avoid portable devices that usually run on battery power, because that is not really "idle time" that would have been wasted (as significantly) anyways17:43
<Nugget> we came quite close to being deployed to a few thousand pay telephones but the person behind the scheme couldn't get management approval.
<BovineOne> we've always been focused on trying to efficiently use just the idle time on machines that would normally be running anyways.
<Decibel> FWIW, I mis-spoke on the physical size of the database... it's actually 3.5GB17:44
<BovineOne> there admittedly are some CPU power consumption differences between an idle and non-idle system, but in general that's much less significant when compared with the machine being turned on or not
<Questions> ootte_ asks: Did somebody think about an autoupdate feature of future clients? It would make it easier to maintain a larger client base.17:45
<Nugget> if you have a platform in mind, http://www.distributed.net/source/ is a good start. :)
<Leto_> I had some parts of the client running on a Tivo once, too.
<BovineOne> we've intentionally avoided auto-update features so far because of many issues17:46
<Leto_> That link that Nugget pasted will be updated with new code very soonish now, btw.
<BovineOne> like security issues, and user preferences, and machine policies
<bwilson> With as many participants as we have, we would be quite an attractive target.
<Leto_> make that, the lastest code is already on that page.
<BovineOne> it's of course also much easier to bring down the entire network if a bad update gets automatically sent out.17:47

some users also prefer to run older versions just because of speed (minor) benefits or different behavior of older clients.

and there will probably be higher bandwidth costs of pushing out every minor update that is not essential.17:48

we'll probably keep an open mind in the future for some sort of auto-updating, but we're currently not focusing any effort to try to provide it anytime soon.
<Questions> CalicoJak asks: are there any plans to bring stats for older projects like RC5-56 back online?17:49
<Nugget> yes, absolutely.
<Decibel> Nugget was bugging me just the other day, in fact. :)17:50
<Nugget> the rc5-56 stats data was "stuck" at hfdirect.com for a time, but we've recovered the data files.

There's really only one thing that will make importing rc5-56 logs difficult and that's the detail that rc5-56 predates the current teams mechanism in stats.
<Decibel> CSC stats should have actually been online right now, we just missed the fact that they're broken.
<Questions> SlicerAce asks: When are we going to get the graphs back in stats???? :P17:51
<Nugget> Probably worth mentioning that when we moved to using participant ID #'s, the participants from the rc5-56 logs were factored in.
<BovineOne> The scripts that drive stats plots at www.distributed.net/statistics/ are very prone to breaking and sometimes require manual effort to get them going again17:52
<Decibel> Daa used to maintain those graphs, but unfortunately he's had very little free time for quite a while now.17:53
<bwilson> The charts for OGR are especially pernicious, and are nearly impossible to automate in any reasonable fashion.
<Decibel> as you can see by looking at the bugs assigned to statsbugs@d.net, there's a lot of stats stuff we'd like to do, but unfortunatly it's difficult for our current staff to find the time17:54
<BovineOne> I'm sure there will renewed interest from our staff to get graphs for our newer projects (as we begin them) online, and that some effort will be made to try to get things improved at the same time.
<Questions> Brekkie asks: Now that the concept has been proven to work in the real world, what is to stop a group with malicious intent from using similar distributed processing systems to break encryption on sensitive data such as encrypted online banking session?17:55
<bwilson> We are always looking at ways to make stats more generalized, so we can use one set of code to display all the projects.
<Decibel> Yes, and thanks to a lot of work by Paul, we're at the point where almost all of the PHP code is generalized.

This makes adding new features much easier.
<BovineOne> of course the major hurdle is assembling that large of a processor pool.
<dbaker> Well, you certainly need to have the computing power resources. The amount that we have would be hard to find, certainly, and this amount of power has only allowed us to crack a rc5-64 message over a matter of years.
<bwilson> Nothing prevented such groups from doing so before us.17:56
<dbaker> You would need significantly more to conquer the more advanced methods of encryption used for online banking and the like.
<bwilson> In fact, we wouldn't have taken this on unless we already knew it was possible and practical.
<Nugget> I do feel that there is significant risk of worm-deployed malicious distributed computing engines, however.
<dbaker> The reality is that no method of encryption is good forever. The question is always, "how long does this need to remain confidential for?"
<Leto_> remember, the encryption required for online banking is very time-sensitive. you need to hack it almost realtime for it to be useful
<BovineOne> we've been the target of worms that maliciously deployed our clients on invaded machines several times before, as you can see from http://www.distributed.net/trojans.html
<Decibel> There has also been more awareness of how weak some encryption schemes are. I'd like to think we've played a part in that.17:57
<Questions> punchcard asks: What 'stage' do you see the distributed.net client/proxy network at? Do you view it as an alpha work in progress, or would you consider it a fairly fleshed out distributed computing platform? Can you tell us a little about some of your future plans for the d.net infrastructure?17:58
<BovineOne> with more recent worms that leverage always-on networks and P2P communication, the possibility of setting up such a malicious network is indeed an increasing risk. The solution is to simply try to stay ahead of those people.

Our current setup is very good at what we've need it to do, but it continues to be very special-purpose and is not extremely flexible.17:59

s/need/needed/

we've also been forced to maintain some level of control over some parts of the source to our clients, which is clearly non-optimal.18:00

one of the things that we're trying to do in future versions is design ways to leverage public-key security a little better to allow a web-of-trust and filter our malicious or cheating clients in the network.18:02
<Questions> nard asks: Will d.net ever do a distributed factoring contest?
<BovineOne> (a document I wrote long ago that describes some of these trust issues is at http://www.distributed.net/source/specs/ opcodeauth.html )
<acidblood> There is some research going on regarding the factoring contest.18:03

We have analyzed the algorithms currently available and found out the Elliptic Curve Method of Lenstra to be the best-suited for our network.

We hope to make it available for our members soon, although it should be clear that RC5-72 is our priority right now.18:04
<Questions> Spin asks: We're running OGR now, there's just GOT to be some way to get a progress meter! Any Possibilities?18:05
<bwilson> It's not any easy question to answer.18:07

OGR is fundamentally different from the other projects we've undertaken. It has forced us to grow in ways we didn't anticipate with the crypto projects.

In particular, the result is an exhaustive and verified completion of the workspace. We can't say we're done until it all checks out.18:08

It wouldn't be a problem to show our progress except that it's very hard to determine what is actually verified and meets the standards.

We are working on changes to OGR, but we again have to ask for patience until we get RC5-72 up to speed.18:09
<Questions> stealth`` asks: Why does PowerPC's have higher keyrates than the x86, even if a faster x86 is compared to a slower PowerPC?
<acidblood> G4 CPUs have some architectural features very suited for RC5.18:11
<Questions> koremore asks: To add to that, why do AMD processors give better keyrates than Intel ones?
<acidblood> First, in the fastest cores, all processing is done in the vector unit of the chip (Altivec).

Intel and AMD CPUs do have integer vector units (SSE2 and MMX), but they're less suited to RC5 than Altivec for two main reasons:18:12

More registers available (32 in the PowerPC versus 8 in MMX and SSE2), plus 128-bit wide registers (MMX is only 64-bit wide), and the existence of a hardware vector rotate instruction in Altivec, which isn't available in MMX and SSE2.18:13
<PeterDoubt> It would be a lot more surprising if completely different CPUs performed exactly the same.
<acidblood> These reasons make it less worthy to use vector units on x86, where all processing is done in the standard scalar ALU.

Oh, and did I mention that the vector unit allows for the processing of 4 keys simultaneously?18:14
<bwilson> (More information about OGR progress reporting is at http://n0cgi.distributed.net/faq/cache/2 30.html)
<acidblood> Second question (re: AMD faster than Intel):
<davehartM> The most recent AMD processors have better hardware rotate support than the most recent Intel ones, to answer the second question. RC5 uses rotate _a lot_
<acidblood> The AMD Athlon possesses 3 superscalar ALUs, all capable of doing a rotate instruction with single-cycle latency.18:15

Given that rotates are the core of RC5 processing, this is very advantageous for the Athlon.

Also, the P4 latency for rotate instructions is 4 cycles, and while I'm not sure off the top of my head whether it has 1 or 2 superscalar barrel shifters, it is clearly in disadvantage here.18:16
<Questions> telexl asks: I notice that the keyserver message hardly ever changes. Will anything useful ever be done with it? (Could it display current server load or something similar?)18:17
<dbaker> The intent of the proxy message was originally to notify users of network problems, project announcements, and such. Once the network became significantly more advanced and stable, there were far fewer announcements to be made. As a result, it became just a silly way to humor users and allow the proxy operators a creative venue to express themselves.

I'm not sure that notifying every client that connects about the current network utilization or statistics would be particularly useful. It seems that it would add extra work to the proxies (keyservers) and be largely ignored by the clients that are connecting. It would be just as easy for an interested user to view the proxy status page (http://n0cgi.distributed.net/ogr-proxyi nfo.html).

However, if there's significant demand, we could look into making it a bit more interesting, one way or another.
<Questions> ootte_ asks: Will there be a GUI-client again (to attract more people and stuff) - e.g. some cool screensaver ?
<BovineOne> Admittedly the Win32 client is pretty nice right now. It has a graph mode in it now, if you haven't noticed.18:18

but we have been investigating ways of providing an optional open socket that can be interfaced with from external programs.18:19

this would open up the possibility of XML-RPC or SOAP based communications and a lot of exciting third-party addons18:20

we came up with a design a long time ago about this at http://www.distributed.net/source/specs/ xml/xml-spec.html18:21

that was before SOAP became as "common" as it is today. we still might implement something like that in the near future.

Here's a picture of the graph on the current Win32 client, in case users on other platforms haven't seen it http://gallery.distributed.net/screensho ts/aar18:22
<Questions> drdink asks: What is the relationship between UD and DCTI?18:23
<BovineOne> and we do have a screen saver front-end that lets you run any other screensaver of choice
<Nugget> Just as distributed.net is confident in the continual role of non-profit participation in the field of distributed computing, many of us are also optimistic about the commercial viability of this technology in other arenas.18:24

United Devices is a commercial venture pursuing the profitable deployment of distributed computing as a technology to displace more traditional high performance computing resources.18:25

many of the "core team" at distributed.net are also employed at UD and are in the blissful position of being paid to do what we've been doing for free for the past six years.18:26

at a very basic level, UD helps sustain distributed.net by employing us and also by donating equipment and bandwidth to the distributed.net network.
<Decibel> The nice, powerful stats machine I talked about earlier was donate by UD, as is the colo space it occupies.18:27
<Nugget> distributed.net has benefitted also from having many of its key staff all relocate to Austin which has been a major benefit to our effeciency and communications.18:29

UD has been completely overrun with cows, too.

It's been a great experience, from both perspectives, in my opinion.18:30

Having my day job so closely aligned with distributed.net makes life a lot less complicated.18:31
<Questions> ertyu asks: Do you think realtime stats are going to viable in the future?
<BovineOne> it's of course been great fun being able to work face to face with people you've met and been cooperating with over the net, although we still mostly call each other by their irc nicknames. :)
<bwilson> There are a couple of reasons realtime stats just aren't a good idea.18:33

First of all, it's not so easy to quantify how much you've improved day to day when everyone submits work at different times.

The other is, we found that the more frequently we update stats, the more people are likely to flush and immediately hit the website to see what it does to their numbers.18:34

We want to reward people for participation, but we also want to manage our resources effectively, including our website.

To get true "realtime stats", you either have to change your definition of realtime or of stats.18:35

Besides, when you're talking about a project that can take 5 years to complete, waiting overnight doesn't seem like long to wait.

Realtime is also a problem because it can take some time for completed work to make its way through the proxies, to the master, then over to the stats server.18:37
<Decibel> Realtime stats would also present a huge load to the stats machine.
<bwilson> Yes, when you look at the volume of work submitted for all projects, from all users, it's a serious amount of data to be thrown around the network.18:39
<Questions> tycoonjack asks: when is dbaker's spyder going to break again?

Junics asks: why does dbaker always get the blame for stats downtime? (among other things)
* dbaker cries18:40
<Nugget> because it's always his fault? :)
<PeterDoubt> Because he's our designated scapegoat.
<Questions> ERaser_ asks: Sorry if this has been asked before, but, In RC5-72 will the clients be able to test keys at roughly the same rate? What are the influencing factors on that? Is the size of the block which must be decrypted different, etc?
<Moonwick> You wouldn't believe what that position pays, too.18:41
<Nugget> there was some initial concern that rc5-72 rates would be markedly worse than rc5-63 on 32-bit architectures, but now it's looking less likely that the performance hit will be anything more than negligible.

er, rc5-64.18:42
<acidblood> The amount of work to be done is the same.

The problem is that key storage requires 72 bits, which is rounded up to 96 bits or 3 registers in 32-bit CPUs. RC5-64 used to need 2 registers per key.

So this is mostly a register allocation headache (on register starved architectures such as x86, of course.)18:43

But probably other architectures, especially RISC ones, won't be so affected.

If anyone is willing to take on the challenge of optimizing the RC5-72 cores, we are going to release a new public source snapshot very soon at http://distributed.net/source/.18:45
<Questions> Dutchman asks: I understand that for the RC5-72 contest the entire code-base of the client is going to have to be re-written. On what time-frame can we expect new clients showing up, and ultimatly, the RC5-72 challenge starting?
<BovineOne> actually the preliminary rc5-72 client source is already available at that url (even though client binaries are not yet available)18:46

The changes to the servers and proxies are already mostly done but need to undergo some internal testing before we are ready for the first volunteers.18:48

The client work is also mostly done, but there will continue to be optimizations for quite a while.

it will probably be at least a week or two before we're ready to start things formally. we'll announce when we're ready18:49
<Questions> waldtraut asks: is the code for the proxyper's also to change due to the move from rc5-64 to rc5-72?18:50
<BovineOne> there may be some beta testing opportunities before then. hanging out on our irc network is a good way to possibly be included, since we tend to leak details out there first.

sure, there are changes in the proxyper too

the proxyper codebase is basically the same as the server codebase that runs the rest of our network, just different #ifdefs18:51
<Questions> jlcooke_crackMD5 asks: I'd like to suggest a new project that impacts industry directly, has a 2 year time line and satisfies your 3 principle missions: development, deployment advocacy. I call for an attack on one of the most widely used algorithms - MD5. http://www.certainkey.com/dnet18:52
<trashover> We can consider it at a future date but our priorities now are rc5-72, ogr, and ecm18:54
<Nugget> we're always open to bringing people on board to speed things along, though.
<trashover> The primary barrier to new projects is finding coders who will come on board and develop them
<Nugget> distributed.net is a volunteer effort at all levels and the best way to get things done has always been (and will always be) to just do them.18:55
<acidblood> We also suggest you join our irc network, so we can discuss further details of your project.
<BovineOne> some of my cow-orkers at UD had suggested the possibility of having distributed.net doing MD5 as well just a few days ago too
<bwilson> we're all in favor of giving our participants more options.18:56

After all, it's a shame to let all those computers sit idle while we pull RC5-72 together. We'd much rather give everyone plenty of great options so they never feel like they need to find something else.18:58
<acidblood> Let's not forget that each coder has his own pet projects and is going to work on them primarily.

Coming on board is the best way to see that your project gets done.18:59

(pet as in favorite)
<Questions> Blain asks: Could the stats processing code be released so that some of us could help make it harder to break?19:01
<Nugget> http://cvs.distributed.net/cvsweb.cgi/
<Decibel> Actually, it is public
<Nugget> It's always been available.
<Decibel> There's also a slew of bugs in our bugzilla for stats to-do items.19:02
<Questions> telexl asks: Is there much point me running rc5-72 on my ancient Amiga 1200, assuming that I can?
<Decibel> (In case you're looking for ideas :)
<Nugget> Absolutely. I encourage everyone to participate with machines like this to increase the liklihood of our finding the key with slower hardware.
<BovineOne> Be warned that block sizes for rc5-72 will be larger than they were for rc5-64, though how large they will be is still up for internal debate before we release the project officially19:03
<Questions> xpndr asks: if i'm not a coder and not so computer experienced but want to help dnet more then just running the client, what should i do?19:04
<BovineOne> Processor speeds have increased greatly since we originally chose the 2**28 block size for rc5-64 so we're trying to take that into account.
<trashover> By the way, someone asked what is ECM. Well, ECM stands for Elliptic Curve Method. It is one of the best suited algorithms for massively parallel processing (with low communication overhead), and we plan to use it for our factoring project -- which is initially going to tackle the RSA Factoring Contest.
<bwilson> There are plenty of ways to get involved without any coding experience.19:05

Some of the more administrative tasks often suffer simply because nobody has time to sit down and do it.

We have a number of people who help by answering questions that come to our help@distributed.net address. Your own familiarity with using the client serves well her.19:06

er, here.
<BovineOne> Of course, attracting additional participants or starting your own team to attract others is probably one of the best ways you can help out (besides running it on your own machines).
<acidblood> With the standard disclaimer of only running the client in machines you're authorized to do so.19:07
<bwilson> The website needs updates, which requires only light HTML knowledge.
<Questions> drwiii asks: You guys mentioned your IRC net earlier, want to give us all some more info on how to connect?
<Nugget> irc.distributed.net on 6667, or ssl-encrypted on port 994.

although many of us are here on SlashNET all the time as well.
<BovineOne> go to this url for IRC information http://www.distributed.net/docs/tutor_ir c.html19:08
<Decibel> You'll find us in #distributed.
<Questions> hanfed asks: Hi from Italy. Here everybody knows about SETI but as soon as I explained about dnetc I gathered a good team. Do you think you can reach media massively with RC5-72 like SETI did?
<BovineOne> Word of mouth has been the primary way we've always drawn participants.19:09
<Nugget> It's difficult to encapsulate the goal and mechanics of rc5 into a small magazine sidebar, but we try whenever we can.19:10
<BovineOne> SETI has had the benefit of attracting attention from the media and the press, in part because of their relationship to other large organizations and also due to the public-interest of aliens.19:11

Admittedly, we tend to be more appealing to geeks, which has slowed our growth. Though we predate SETI, their popularity has also increased awareness of our projects.19:12
<Nugget> When SETI came on the scene we saw a spike in our growth. Presently the number of computers participating in our, or any, projects is such a small percentage of the potential pool of machines that it's difficult to view the situation as a competition.19:13

We are more interested in seeing that cycles do not go to waste and all of the public projects help in that regard.19:14
<Questions> TimLaptop asks: Are there any Itanium/Opteron specific optimizations being done or being looked into? If so, which platform looks most favorable?
<acidblood> First, I'd like to say that 64-bit machines do not help RC5 in any way.19:15

In fact, they hinder RC5, since the algorithm calls for modulo-2^32 arithmetic, which is just a fancy way of saying that all arithmetic should be done in 32-bit registers and truncated whenever it exceeds that.

So, basically, we need additional instructions to ``simulate'' a 32-bit machine inside a 64-bit one.19:17

That said, the most difficult thing about optimizing for the Itanium is getting ahold of one. One of our coders is admittedly looking into it, so expect some advances in the future.19:18
<drwiii> I'd like to take this opportunity to thank Nugget, dbaker, acidblood, bwilson, BovineOne and anyone else I might have missed for taking the time to talk with us tonight.

We ran for about 2h:20m tonight, and relayed whopping 35 questions.

We'll have a forum log available in a bit at this URL: http://www.slashnet.org/forums/
<acidblood> As for Opteron, it's rather hard to optimize for a machine that doesn't exist yet. It might even not be worth it, due to the 64-bit issue explained above, so we might stick with native 32-bit x86 code.
<BovineOne> even though there may not be any inherent benefit of those 64-bit platforms, there will undoubtedly be someone who helps us impove our core performance on those platforms19:19
<acidblood> Also, AMD hasn't published specs about instructions timings on the Opteron yet, so it's really impossible to do anything at this point.
<bwilson> It has been very encouraging to see so much interest, and that we have lost so few people from the forum even though we've gone twice as long as planned.
<drwiii> Once we get the go-ahead, we'll drop the moderated bit and make it a free-for-all. Thanks again for showing up! :)
<Nugget> Cows are cool.
<BovineOne> ]:8)>19:20
<Leto_> Moo!
* DrkShdw drinks some milk.
<Nugget> Thanks again to SlashNET for sponsoring the Forum.
<trashover> mo_O
<acidblood> We all look forward to seeing everyone running RC5-72 as soon as possible.
* bwilson pets the cow
<acidblood> And other exciting projects in the future.