Tim Charron 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.

Tim Charron
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 mailing list