[cap-talk] impossibility of solving the "coordinated attack problem" ("generals problem")

[Ian G]

David Hopwood wrote:

> It seems to me that the significance of this result is often overstated, though.
> The purpose of using an unreliable channel (or a less reliable one), is usually
> that such channels are less expensive, and so using them reduces the average
> cost of some kind of transaction.


I would interpret it differently.  I would say that
the usefulness of the result is to show that there are
no reliable channels.  Full stop.  And that you have
to construct your system with that in mind.

Which is to say, we can build systems that work but
assume a "very" reliable channel, but we can't rule out
that we may hit the one time that the very reliable
channel fails.  So we are left with an important albeit
rare exception case (which you treat below by using yet
another uncorrelated channel).

Or, we can just assume unreliability, and build as if
all channels are unreliable.  Which means we have no
exceptions to deal with, just routine unreliability.

It's a tradeoff.  Most all systems go for the first
path (using TCP/IP and assuming very reliable).  But
then those systems that want real solid reliability
generally end up having to back out their assumptions
and become message oriented.  That is, assume all
channels are unreliable.

> The result doesn't preclude the existence of protocols in which the outcome
> is either that two parties agree on an outcome, or (with low probability) that
> one party thinks that the protocol completed successfully and the other party
> *knows* that it hasn't.


Right, it doesn't preclude agreement, it just precludes
certainty in that agreement.

> Suppose, then, that the parties delay acting on the outcome for some time T.
> This gives the party that knows that the protocol did not complete successfully,
> time T in which to attempt to communicate this, over channels that may be more
> reliable or have different failure modes to the original channel.

iang