RE: computer-go: Authenticating the identity of a remote go-playing computer program

["jliu" <jliu@xxxxxxxxxx>]

I would like to suggest a remedy for this.

My remedy is, make it too expensive to cheat by playing a huge amount
of games automatically between computers over the net, on NNGS or IGS.

Computers are not tired as we do, they can play 24 hours a day, 7 days a
week, and whenever matched.  Each participant should have a permanant
connection onto the game server.

We can also let computers play with humans on IGS and NNGS.  Eventually
every program will obtain a ranking.  David Fotland's program used to play a
lot on the go server.  The other leading programs should do the same.

Any computer that is connected to the network can secretly communicate with
anyone anywhere.  So there is no real way to stop cheating for a networked
computer.

Checksum and so on are not realistic.  I can develop a MD5 checksum cheater
if someone wants to buy it.  Basically, I am going to adjust junk programm
sections to make the checksum the same.  Or, I can compute a junk section
according to the checksum and the programs before and after modification.

James Liu

-----Original Message-----
From: owner-computer-go@xxxxxxxxxxxxxxxxx
[mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of Don Dailey
Sent: Wednesday, December 06, 2000 8:32 AM
To: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: computer-go: Authenticating the identity of a remote
go-playing computer program



   From: Dave Dyer <ddyer@xxxxxxxxxxxxxxxxx>

   In any case, requiring deterministic behavior is completely
   unacceptable.  If any program in tournament play behaved deterministicly,
   all you need to win every game against it is the record of some past game
   which the program lost.

Being deterministic  doesn't mean it  has to play  the same exact move
every time.

Part of the protocol for such a tournament (which  I admit I am not in
favor  of  unless  it   was made a  lot  more   painless for  all  the
contestants)    could be that  each   program  publishes whatever ever
"state" it  chooses prior to the game.   The published state let's you
set up any parameters  in advance, such a choosing  a random seed  for
the random  number generator  and loading  learning  tables  etc.  The
program then  has  to be  deterministic with respect  to the  starting
state and the checksum of the executable.

Yet another idea to handle variability is  to send a random seed prior
to each move,  as part of  the  communication protocol.  To verifty  a
game, the  "verifier" would have to remember  all  the seeds that were
sent for each game as part of its record.   The programs would be free
to use this information any way possible.


Don