[RC5] CSC - RC5-64 Comparison and Moo Payback Calculations

Wilson, Bruce bwilson at fers.com
Thu Dec 2 14:11:00 EST 1999

Hash: SHA1

...and if gold sold for $10, and lead for $15, then hey, lead is worth
more than gold!  I proved it!  (Imaginary statistics lead to imaginary

But seriously...

If the "moo" is such a big deal to people... how hard would it be to
write a little c app (on most platforms!) which can:

1)  Read the file date of the -out.rc5 and -out.csc files
2)  Sleep for a configurable number of seconds
3)  Check again
4)  If it's changed, moo
5)  Repeat from 2.

It will certainly be much easier to implement, requires no changes
(size or complexity) to the dnetc app, and has absolutely no impact on
those people who don't want it.

For the record, I'm a Win32 (NT) person who could care less about
whether my machines moo at me.  I'd rather have the keyrate.

Bruce Wilson, Manager, FERS
bwilson at fers.com, 312.245.1750, http://www.fers.com
PGP KeyID: 5430B995

"Give me ambiguity or give me something else."

|-----Original Message-----
|From: owner-rc5 at lists.distributed.net
|[mailto:owner-rc5 at lists.distributed.net]On Behalf Of Zorba the Hutt
|Sent: Thursday, December 02, 1999 13:56
|To: rc5 at lists.distributed.net
|Subject: [RC5] CSC - RC5-64 Comparison and Moo Payback Calculations
|Heh, just noticed something vaguely entertaining . . . as of 
|the next stats
|update, I predict that our CSC completion will pass our RC5-64 
|despite the (relatively) glacial keycrack rate of the clients. Sure
|demonstrates the difference eight bits makes, doesn't it? Two 
|month ETA to
|end of keyspace at current rate, meaning a 50% completion 
|probability in one
|month. Personally, I'm betting it'll be over before that, just because
|people might still be switching over to the CSC client, 
|although without the
|moo, we might have as many converts as we're going to get.
|Which leads me to my next comment - an argument for adding 
|Pretty Statistics
|and a Moo back to the Win32 GUI clients. To convince people, I 
|have pulled a
|large amount of statistics out of thin air, because I haven't 
|got a clue
|what the real numbers are. I hope this convinces someone :)
|First: We are currently cracking RC5 (as of however often the 
|main page gets
|updated) at 83.79GKeys/sec. Pre-CSC it was higher - I'm gonna call it
|90GKeys/sec. Let's assume that 50% of this is due to Windows 
|users, making
|45GKeys/sec. (Incidentally, I will cheerfully revise these 
|calculations if
|anyone can pull out better statistics for me). OK, now of this 
|let's assume that our Win32 GUI Team has added a Glitzy Crack 
|Mode (GCM). It
|has a screensaver setting with lots of pretty flying colors 
|and meaningless
|indicators, but it looks good, and that's what matters. First: half
|our users are going to turn the GCM off (22.5GKeys/sec). However,  the
|addition of the GCM makes the client run . . . ONE PERCENT slower. 
|(Incidentally, one percent slower is absurd, our coders are better
|than that. This is "for argument's sake".) So our Non-Glitzy Users are
|going to have a combined keyrate of 22.275GKeys/sec. Now, our other
|half of the users  are going to leave it on, and let's assume that the
|GCM uses 10% of the CPU  when it's actually being pretty (I think this
|is pretty high also, depending on complexity I'd guess 1% to 5%.
|Consider that these are  probably not going to be high-quality 3d
|renderings, this is more likely to be text  and sprites). So anyway,
|our Glitzy Users are going to give us a combined rate of
|20.25GKeys/sec. Add these together, and we have  42.525GKeys/sec. Add
|this back to the half of the keys that aren't coming from Windows 
|users, and we get 87.525GKeys/sec. Now, 2.5GKeys/sec (roughly) is not
|that big of a sacrifice. Taking a look at the stats, we see that there
|are about 15 thousand users that contributed blocks to RC5 yesterday,
|and  15 thousand users that contributed blocks to CSC yesterday. Now
|I'm going  to pull even more numbers out of my hat and simply add them
|together.  (Consider: a user might submit a block to rc5 and csc,
|especially if they're  maintaining lots of systems that can't be
|updated easily. Consider: a user  might have more than one day's of
|blocks buffered, and therefore not have contributed anything
|yesterday. Perhaps we need an "active users in the past week" stat?)
|So we get 30,000 active users at dnet total. Call it  half of those
|are Windows users - 15000. Say we could attract 5% more users  by
|adding a glitzy interface. 22.275GKeys/sec / 7500 users (assuming that
| half the users are glitzy) = 0.00297GKeys/sec/user.
|0.00297GKeys/sec/user *  750 new users (do the math yourself on that
|one) is 2.2275GKeys/sec. Making our New Revised Keyrate . . .
|OK, so we've lost a quarter of a gigakey per second. But 
|considering that
|these are total ballpark answers anyway, I don't think it's 
|too bad, and if
|we cut out the 1% penalty for adding the option to the clients (which
|I still think would never happen - we're talking one percent of  a
|percent, MAYBE) then we make a profit. And I'm almost certainly 
|screwing up on the actual numbers here, but, hey. Someone give me
|better stats so I can recalculate!  
|To unsubscribe, send 'unsubscribe rc5' to 
|majordomo at lists.distributed.net
|rc5-digest subscribers replace rc5 with rc5-digest

Version: PGP Personal Privacy 6.5.1


To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list