I was going through the "proof" that Pb (Plurality Benham) is monotone, and then I found out it doesn't work after all, because it requires a property that Plurality fails. I thought that the failure could only happen in the case of a tie, but that's not the case. Here's an example: 8: A>B>C 2: B>A>C 5: B>C>A 6: C>A>B This is an ABCA cycle and the Plurality order is A>B>C. So C gets eliminated whereupon A beats B pairwise and wins. Now two B>A>C voters raise A. The result is 10:A>B>C 5:B>C>A 6:C>A>B It's still an ABCA cycle, but now the Plurality order is A>C>B. So B gets eliminated and then C beats A pairwise and wins. Raising A made A lose -- monotonicity failure. The base method property that I think will make a Benham-style algorithm monotone is this: Suppose A is the winner and there's a cycle A>B>C>A, with B>C in the base method's social ordering. Then raising A must not move C above B in that social ordering. Plurality, not having a concept of pairwise victories (much less beatpaths), fails this. But it's far from clear how one might combine this property with the pairwise burial immunity that Plurality does have, and that's necessary for a Benham-style algorithm to pass DMTBR. (Pairwise burial immunity: Voters who prefer Y to X can't push Y above X in the social ordering by burying X on their ballots.) But at least Pb shows that DMTBR + Condorcet + summability is possible. That's something! (I didn't get what I expected - but I got something I didn't expect.) -km