Thanks, Benja and cousin_it, for working out the math. The “new” G_M looks correct to me (and let’s just call it G_M from now, since I see no reason why the joint machine can’t be programmed with a correlated strategy profile). To make it a little more realistic, we can add a step after the joint machine is constructed, where each player has a choice to transfer his resources or not. It’s pretty obvious that adding this step makes no difference in the outcome, since the players can program the joint machine to execute their fallback strategies if one of the player fails to transfer.
Benja’s method for G_S to enforce correlated play in G seems to require simultaneous source-swapping. Otherwise, if I choose my random number first, then the second player can pick his number to favor him, right? It seems that the common quined program has to use some cryptographic method to generate a common random number in a way that’s not vulnerable to manipulation by the players.
Thanks, Benja and cousin_it, for working out the math. The “new” G_M looks correct to me (and let’s just call it G_M from now, since I see no reason why the joint machine can’t be programmed with a correlated strategy profile). To make it a little more realistic, we can add a step after the joint machine is constructed, where each player has a choice to transfer his resources or not. It’s pretty obvious that adding this step makes no difference in the outcome, since the players can program the joint machine to execute their fallback strategies if one of the player fails to transfer.
Benja’s method for G_S to enforce correlated play in G seems to require simultaneous source-swapping. Otherwise, if I choose my random number first, then the second player can pick his number to favor him, right? It seems that the common quined program has to use some cryptographic method to generate a common random number in a way that’s not vulnerable to manipulation by the players.