Author: Robert Hyatt
Date: 19:42:04 02/16/99
Go up one level in this thread
On February 16, 1999 at 11:44:25, KarinsDad wrote: >Robert, > >It is unfortunate the position you are in. > >You have a great research project which is abused by others, but at the same >time, you are a person who wants to share his ideas without seeing others harmed >by that sharing. > >I see no simple solutions. > >Yes, you could try the following: > >1) Release new versions of Crafty source with some key elements missing so that >it will not compile. >2) No longer release Crafty source except to some few trusted individuals who >have in the past given back to the Crafty project. >3) No longer release Crafty source, but put your ideas into other forms of media >such as white papers or books. >4) Continue as you have and watch the problems propogate. > >Like I said, no easy answers. > >One idea I had is to extend #1 and #2 above by creating a "keyed" version of a >.dll that requires a special user name and password. Each keyed DLL is specially >created by you and requires a different user name and password. In this manner, >you could give out a different DLLs to select individuals that you trust and >everyone else would have to earn that trust. > >Also, each DLL forces a display on the screen and in communication across the >Internet stating that this is "Tom's" version of Crafty playing. This way, >nobody could run the new code in a tournament without it getting documented that >Crafty was running. > >Now this would take some work to ensure that the routines within the DLL are >both critical and hard to reproduce, however, it probably could be done. > >You could also have a generic DLL that you could give out with the source. This >DLL would have to be linked in and used with the code or the code would not work >properly (dropping 300 ELO would probably be sufficient). This DLL would also >advertise heavily that Crafty is running. The released source version of Crafty >with this DLL could also be forced to play at 150 ELO or so less since it is not >using one of the "trusted" DLLs. > >Of course, none of these solutions will resolve problems with Crafty source that >is already out there. But, what is done is done. > >Hard measures for hard times. > >Good Luck with whatever you decide. > >KarinsDad :) ;) I've done one thing already that I suppose won't hurt to reveal. Way back in the SMP development, I thought about this problem. And I made a couple of 'assumptions' that are wrong about some things I do in the SMP search. These 'wrong' things can be avoided by subtle programming things, but if the code is changed in the wrong places, the SMP search breaks in subtle ways. It causes me a lot of grief as when I make changes and don't check these 'tripwires' I trigger them myself and do a lot of debugging. I won't say more, other than that at least 'copying' the SMP code line for line is guaranteed to produce two nice 'glitches' that will produce amusement when they show up. But they are subtle. I only wish it was 'easy' to make the 'copy' act up upon demand... but the bugs are more subtle than that, unfortunately. If someone studies the SMP code _very_ carefully, the problems can be exposed. But that is the point... because at least they have to understand the algorithm to make it usable, or else run the risk of some 'interesting behavior'... So I have taken one step at least, but only WRT the SMP stuff. (one of these problems was simply a bug that I had to find before the current SMP algorithm was functional in early 15.x versions. But it was cute enough that I decided that this was the 'perfect' protective mechanism, and I just chose to fix the 'symptom' rather than the actual problem.) Let's just see what happens...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.