[cap-talk] Why is EQ so dang fascinating?

[Charles Landau]

At 1:08 PM -0700 11/3/07, Dean Tribble wrote:
>  > >In typical cases, the
>>  >operation completes in bounded time for cooperating participants, and
>>  >only takes unbounded time for malicious participants. With
>>  >non-blocking send, that need pose no burden on the evaluator
>>
>>  It imposes the burden of choosing the right timeout, which is
>>  notoriously difficult.
>
>Indeed, it's sufficiently difficult, that I was not suggesting a
>timeout. Instead, in previous scenarios, only success mattered, and
>success requires forward progress.

I wasn't thinking so much about "previous scenarios" (grant matcher) 
as I was "typical cases".

Let's consider a concrete example. Suppose I am given a capability 
that purports to be a purse, but is deliberately malicious. I go to 
the bank to deposit its contents into my purse. Lacking EQ, the bank 
invokes the suspect purse and waits for a response.

As a customer of the bank, I want to know whether the lack of 
response is the fault of the suspect purse or the fault of the bank. 
With EQ, the bank wouldn't need to invoke a malicious purse, and I 
would always know any slow response would be the fault of the bank.

>Designing protocols to be robust against
>high latency often adequately addresses the issue of malicious
>participants being deliberately slow.

I'm curious how you would design a robust protocol in the above 
example, without using timeout or EQ.