I do not think that it is true that it is "very likely" that the solution will be net positive for both players.

In the triangle of possible outcomes, if any of the joint utility points lie in the triangle bounded by x+y>1 (which occupies a quarter of the space of possibilities), then net loss for either player become impossible (and that's a sufficient, not necessary condition for that).

But if you want, you can restrict to strict Pareto improvements over the default...

I do not think that it is true that it is "very likely" that the solution will be net positive for both players. If players have a variety of marginal utilities from resources, it seems reasonable to expect that this will cause most 'negotiations' to result in pure redistribution, and there are many cases (such as Wei_Dai's second example) where one can simply lose all their resources.

It also seems like a very bad assumption for agents to assume that they'll be exposed to these situations symmetrically; most agents should be able to have a rough idea where they lie on the spectrum compared to their likely trading partners.

More than that, in a world where this was an enforced negotiating style, it seems that you have a dystopia where the best way to gain utility is do a combination of modifying your utility function such that you gain transfers of resources, and/or seeking out trading partners who will be forced to give you resources, and that such efforts will rapidly consume a growing share of the resources. That is certainly what happens when I game out a real world test, with Omega enforcing the rules!

Nonlinear utility functions (as a function of resources) do not accurately model human risk aversion. That could imply that we should either change our (or they/their) risk aversion or not be maximising expected utility.

What problem are we trying to solve? What are we trying to optimize?

(e.g.: What determines a better or worse outcome of the sum of these deals? Which agents have to agree to it, and what information are they assumed to have access to about the other agents? Which of that information do they have before agreeing to use this method in general? Is it imposed from on high? How much self-modification can agents make to achieve better deals? Etc, etc.)

for reference, here's what I was "planning"-I was all too aware i didn't have time to learn a new language to actually implement it in. a pity i didn't think to post this before the tournament results, even if it's just pseudocode...

run(me,opponent){ //start point notethetime() if(me=opponent){return C} defectbot[]=a list of primitive defectbots with a junk string value added run5times and record results:(run(opponnent, (opponent, defectbot[i]) { if (opponent cooperated sometimes){ if(isooponentclearlymimicbot(ooponent)){cooperate()}else{defect()}}//mimic bot is assumed to be simple and easy to identify as such, but I'm not exactly sure how i'd test this. checktime()//if the opponent takes way too long to run against a short defect bot with barely any baggage, it's going to have trouble with you. Defect for both your sakes.

if(opponent cooperates allways){if(opponentisclearly cooperate-bot){do I cooperate with C-bots in the hopes of cooperating with those who cooperate with C-bots or do I take advantage of the schmuck?}//a decision i really never made...

mimicbot="...." result=(opponent,mimicbot) if(opponent defected{defect()} checktime(){}//but this time, cooperate if things are taking dangerously long-MAYBE. it's somewhat reasonable for an opponent to take a while against a mimicbot, especially if opponent is mimicbot with small epsilon. .

psychbot1.0=("...."+mimicbot+"..."); /psychbot 1.0 sends you against mimic bot, and then does what you do. only, I get to see the final result.
record(run( opponent,psychbot1.0))

checktime();-possibly in a seperate thread. depends on how quickly this whole thing goes.
psychbot 1.1="...+defectbot".
result=run(opponent, psychbot1.1); psychbot 1.1 also checks you against defect bot, like the main program. the purpose, if used, is to avoid cooperating with programs that defect on finding a "D" if(result=C){return C;} else{return D}. }

}

Yeah. pseudocode. for java, not lisp.

edit: clarified a few things in the intro.

I don't know quine at all and can't easily understand exactly what all these guys are doing but:

This is obviously NOT a stable metagame; in both senses.

If we ran this tournament again the random-bots would get utterly destroyed (since it's very easy/fast to check for them and defect). If we ran this tournament with multiple rounds, where successful strategies survive and unsuccessful die, and there was even one defect-against-randombot code in the mix, it will win if it doesn't die early.

My guess-happy summary of what happened is this: The core problem is very hard, so most people instead did something simple, often very simple (cooperate bot, defect bot, random bot - which won!) with a small number of people trying for real. The people trying for real, however, spent all their energy planning for other people trying for real and trying to fool them, rather than trying to act correctly against all the super-simple programs, because if you put in that much work you think other people will mostly put in at least some work (R has an entire long blog post of metagame and strategic analysis which is COMPLETELY wrong in exactly this way, in real life I do this a lot). That, combined with programming errors since the task involved was actually hard, prevented them from winning.

The lesson here, I think, is more about how people react to such tournaments than it is about the actual problem at hand; if anyone had assumed their opponents would either be simple or hopelessly complex, they could have written a program that defects against programs that don't look at their code or otherwise are clearly safe defections, does something hard to exploit against everyone else that likely is somewhat random, and win easily.

I don't know quine at all and can't easily understand exactly what all these guys are doing but:

This is obviously NOT a stable metagame; in both senses.

If we ran this tournament again the random-bots would get utterly destroyed (since it's very easy/fast to check for them and defect). If we ran this tournament with multiple rounds, where successful strategies survive and unsuccessful die, and there was even one defect-against-randombot code in the mix, it will win if it doesn't die early.

My guess-happy summary of what happened is this: The core problem is very hard, so most people instead did something simple, often very simple (cooperate bot, defect bot, random bot - which won!) with a small number of people trying for real. The people trying for real, however, spent all their energy planning for other people trying for real and trying to fool them, rather than trying to act correctly against all the super-simple programs, because if you put in that much work you think other people will mostly put in at least some work (R has an entire long blog post of metagame and strategic analysis which is COMPLETELY wrong in exactly this way, in real life I do this a lot). That, combined with programming errors since the task involved was actually hard, prevented them from winning.

The lesson here, I think, is more about how people react to such tournaments than it is about the actual problem at hand; if anyone had assumed their opponents would either be simple or hopelessly complex, they could have written a program that defects against programs that don't look at their code or otherwise are clearly safe defections, does something hard to exploit against everyone else that likely is somewhat random, and win easily.

Me +1 80% chance

Not very difficult to think of ways to randomly determine a winner verbally without a coin, to be fair.

I don't think a commonsense reading of this rule would prohibit holding one's arms up and saying "Hugs?"