I’d like to explore the differences to the spirit of the competition if, instead of access to the source code of the opponent, players only had an opaque, non-modifiable, callable entity. Feel free to add other additional interesting consequences.
Cliquebots—Opaque source code would make the creation of cliques far more interesting, requiring colluders to construct far more difficult protocols to detect other CliqueBots, and to prove their own CliqueBot status. Insufficient consideration before the competition would allow for CliqueBot cheaters to take advantage of weak criteria. Net effect is reducing the likelihood of a CliqueBot sweep.
Searchability of Special Cases Transparent source code makes the search space for special cases easier and in some cases, even possible at all. A program that explicitly writes. “always defect on program XYZ,” where the bitstring specifying XYZ is arbitrarily large, can be discovered to be so by inspection. With opaque code, the caller could never discover XYZ within 10 seconds for large enough strings.
Recursion Guards/Sleeps—Modifiable code allows one to trivially remove, modify, or add recursion guards and sleeps. With opaque code, a naively written “Call opponent with my source code” gives the opponent a time advantage on returning a result, causing you to run the risk of not-halting if you try to wait for the result, and then the opponent defects on you. Modifiable code forces opponents to be clever about how theysleep, but in an annoyingly hardware and language-dependent manner (cycles per second). Otherwise you can just remove their sleep functions and spoof their timing, and so discover their result without the time advantage.
Stack Counting and VMs—Inaccessible source code makes easier the creation of programs which determine the nature of their caller. Access to source code allows for trivially removing stack counting from a program before calling it. Without access, one must write a VM.
I’d like to explore the differences to the spirit of the competition if, instead of access to the source code of the opponent, players only had an opaque, non-modifiable, callable entity. Feel free to add other additional interesting consequences.
Cliquebots—Opaque source code would make the creation of cliques far more interesting, requiring colluders to construct far more difficult protocols to detect other CliqueBots, and to prove their own CliqueBot status. Insufficient consideration before the competition would allow for CliqueBot cheaters to take advantage of weak criteria. Net effect is reducing the likelihood of a CliqueBot sweep.
Searchability of Special Cases Transparent source code makes the search space for special cases easier and in some cases, even possible at all. A program that explicitly writes. “always defect on program XYZ,” where the bitstring specifying XYZ is arbitrarily large, can be discovered to be so by inspection. With opaque code, the caller could never discover XYZ within 10 seconds for large enough strings.
Recursion Guards/Sleeps—Modifiable code allows one to trivially remove, modify, or add recursion guards and sleeps. With opaque code, a naively written “Call opponent with my source code” gives the opponent a time advantage on returning a result, causing you to run the risk of not-halting if you try to wait for the result, and then the opponent defects on you. Modifiable code forces opponents to be clever about how theysleep, but in an annoyingly hardware and language-dependent manner (cycles per second). Otherwise you can just remove their sleep functions and spoof their timing, and so discover their result without the time advantage.
Stack Counting and VMs—Inaccessible source code makes easier the creation of programs which determine the nature of their caller. Access to source code allows for trivially removing stack counting from a program before calling it. Without access, one must write a VM.