[Cryptography] asymmetric attacks on crypto-protocols - the rough consensus attack

[Jerry Leichter]

>> If one of the protocols is actually *better* along the agreed-upon dimensions - for example, if one has a security flaw - the whole assumption of the "rough consensus" approach is that this will be found eventually and the better protocol will win on the technical merits.
> I'm expecting the two protocols to be quite different and difficult to compare.  This is in order to preserve the tribe that supports each; the two protocols have to be oriented to their own tribe in ways that they appeal and horrify in equal measure.
> 
> Also, the nature of the attack is that the attacker will change the nature of the attack, if it suits...  The essence is the outcome, not the inputs, and this attacker cheats.  So I'd fully expect the attacker to actually improve the underdog if it was losing support....
You never need to outright compare the protocols.  In fact, the nature of arguments of this sort - whether a deliberate attack or just arising by themselves - is that each side simply trumpets the virtues of its own approach, with only minor mention of the other approach.

My assumption is that if there are any significant problems with an approach, they will be found and called out, and that approach will be removed from the running.  If an approach has survived all attempts to knock it out for some appropriate length of time, we assume that it's "good enough".  We usually operate on the assumption that the ranking of approaches induces a total order. I claim that's not true:  When you get to the point where each side is simply listing the ways it's better than the others - and the lists are comparable - then you have two approaches that are simply not ordered with respect to each other.  At that point, you toss a coin.

In terms of actual operation, I'd have the procedure work like this:

1.  Anyone can enter a proposal, or make an argument about proposals that have been entered.

2.  There's a (pre-determined) cutoff time after which no new proposals can be entered.

3.  Some arguments about proposals are classed as "significant attacks".  It's usually obvious which these are; but should there be any debate, an argument shall *not* be deemed a "significant attack on a proposal" unless a super-majority agrees that it is.

4.  Any proposal that's the subject of a "significant attack" is taken out of the running.

5.  If more than one proposal remains in the running, and no "significant attacks" have been mooted in some (pre-determined) amount of time, a random choice among the remaining proposals is made.

This procedure is guaranteed to terminate in a pre-determined amount of time, having chosen 0 or 1 proposals.  It is vulnerable to a "heckler's veto" in clause 3:  A sufficiently large (but under a super-majority) group can block all attempts to kill off a bad proposal.  But it's hard to hide that you're doing this - this is a technical discussion, and if you say "no, that's not an attack" without being able to advance a good reason, people will quickly figure out what you're up to.  I said "a super-majority agrees", not "a super-majority votes" - I'm maintaining the "rough consensus" nature of the interaction.

(Note that it *may* be the case that there are genuinely two distinct audiences with different needs, and no one proposal can really satisfy both.  In that case, you may really not *want* there to be a single winner.  In some cases, providing two alternative approaches, each covering part of the space of application - with perhaps substantial overlap - may simply be the best you can do.)
                                                        -- Jerry