[RC5] They have all our e-mails!!!
jcampbel at lynn.ci-n.com
Thu Nov 14 21:51:02 EST 2002
On Thu, 14 Nov 2002, Steve Bennett wrote:
> Just have to point out the flaw in your logic...you're claiming that
> instead of sending out the message to every participant, they should send
> out the message to the mailing list...which magically gets to every
> participant? Whether you send to a list or individually, you still have to
> send each email individually. Of course, if much less than 100% of
> participants are subscribed to rc5-announce, then you're right, but how are
> those people going to know to get the new client?
The flaw in *your* logic is that not all of those people need to be
- or *should* be - sent notification that new clients are available.
There are large numbers of people who have cracked for d.net in the
past - and whose emails are therefore in the participant database - who are
no longer interested in doing so.
For example, my team had fifty-some-odd members on it. A few of
those were out-of-date addresses for people who'd changed emails and didn't
care enough about stats to merge in their prior work (which is another
problem you're overlooking), but the large majority were distinct
individuals. Call it fifty valid addresses.
Of those fifty, not more than a dozen people had machines cracking
at the end of the project, and several of those looked to be forgotten boxes
that no one had ever bothered taking the client off of. I suspect that some
of those are *still* cracking random blocks because they can't get real work
from the keyservers, didn't have another project to fail over to, and no one
has noticed that they're still doing it. We were only getting regular work
from five or six people... my dual Palomino was accounting for a third of
the keyrate of this allegedly fifty-member team all by itself.
And from what I saw, I don't think that my team was out of the
ordinary. We held position fairly well, with only a small drift downwards,
and we couldn't have done that if most teams had still had most members
cracking. We kept passing teams that had only a couple active members left
out of dozens, and even the top teams had huge swathes of inactive members.
RC5-64 was a *long* project... most people don't have the patience or the
sheer stubborn intractability to keep beating on an encryption problem for
five years. They lost interest, wandered away, and don't care about coming
back, especially not for a project that estimates say will take even longer
than RC5-64 did. Those people - and I'm betting that they constitute well
over half of the addresses that d.net's got in the participant database -
would not be happy about being spammed out of the blue about a project that
they haven't cared about in years.
Even the ones that stayed with RC5-64 through the end might not be
interested in starting up RC5-72. I'm actually in that boat myself... having
proven the concept with RC5-56 and RC5-64, I don't see any value in
continuing on to do RC5-72 (and OGR has never managed to grab my interest),
so I've taken my spare cycles over to other projects that have more use than
just proving that, yes, we can do it again, and bigger numbers take
longer... ECCp-109, 'til we broke that one too, and now protein folding and
particle accelerator design. Come to think of it, I'm not even sure why I'm
still on the list, except that I'm too lazy to unsubscribe, and that we
occasionally get an interesting thread through (though these days it mostly
seems to be people whining about how d.net volunteers spend their time).
But, anyway, the point is, an address being in the participant
database is not an indication that there's someone at that address who's
interested in downloading RC5-72 clients, and is not an invitation for d.net
to spam them about it. People who *are* interested in RC5-72 can find out by
subscribing to the announce list (or this list), checking the website, or
various other methods - intra-team communications, general-purpose tech news
boards, word of mouth, etc. - and therefore don't need to be subjected to a
mass mailing. Many of those alternate methods distribute the notification
load off of d.net's servers, too, which points up another flaw in your
jcampbel at lynn.ci-n.com
QotD: I haven't lost my mind; I know exactly where I left it.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5