[rc5] SOURCE CODE AND REQUESTS FOR OTHER PLATFORMS
tcharron at interlog.com
Mon Jun 23 19:33:35 EDT 1997
> Well, for one, doubting the v1 results which report a non-success and if needed
> reissueing them later (as has been suggested by others) would work pretty well.
> For positive results, doing a verification round might be wise (and should be
> done anyhow, even for v2 or v3 I think, just in case).
I've seen a lot of good discussion on this issue. From what I've
seen, the motivation for producing new clients is twofold. First,
create a common code base with common functionality across platforms
(where appropriate). Second, to reduce the number of unique clients.
The more unique clients there are, the more likely it is that the
solution will be missed. Every packet coming back to the keyservers
is questionable. Having new clients would let the keyserver assign a
higher 'trusted' level to blocks returned from those machines, just
based on the fact that these clients are known to have been tested
extensively before release, and are less likely to have been hacked
to enable spamming of the keyservers without actually checking
It seems clear to me that there's a lot of corporate people who
wouldn't run downloaded binaries on a secure system without
source. (this is one of the reasons I originally compiled a Windows
executable). While this may not be a large percentage of the client
power today, remember that this contest will be going on for a while.
We shouldn't set things up to make it unappealing for a corporate
installation. Think of an admin (or even manager) deciding to
install it as part of a large roll-out. He'd have a lot easier time
justifying it if he actually had the source or had compiled it
I see the ideal as keyservers that accept connections from both types
of client -- 'trusted' (source not freely available), and
'untrusted' (source available, maybe hacked or have bugs
introduced via legitimate 'enhancements'). The keyserver would keep
track of which blocks came in via which method. In the unlikely
(hopefully non-existent) event that the keyspace was exhausted
without a solution, less trusted keys would be tried first. (I know
-- this has been said before -- credit to whoever first posted it).
The trick is to get people to move over to the new client if the old
one is still working. This would minimize the use of personal proxy
servers, and raise the average 'trust' level of the clients. It
seems to me that most people are motivated by the stats. Why not
just let the keyservers accept connections from both versions of the
clients, but not let information from v1 clients reflect in the
stats? Or, let it all reflect under a common email/host. People who
didn't want untrusted code would then have an alternative. The
organizers should also be happy, as they would know who to trust.
The only people who would end up running v1 clients would be those
who had a good reason not to run the v2 ones, or machines for which
nobody remembered to update the client (which would end up as lost
cycles if the v1 clients were not supported)
So, I put the question to all those people who would not
run code without source. Is this a workable solution? You'd have
the source code. You'd still be able to participate, maybe even know
your own stats if you use a personal proxy server. You wouldn't have
any stats reflected in the big picture though.
And to the organizers, would this setup be amicable? You'd still
have access to all resources, and you'd have a way to identify which
blocks came in via untrusted clients. As a side effect, there would
be no motivation for anyone to hack a client to report checked blocks
without actually checking them.
tcharron at interlog.com
tcharron at ctfinance.com
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5