definition of good / bad ERTP issuer?

[dckc]

What is the Problem Being Solved?

We have discussion of Limited Risk from Bad Issuers and we sometimes speak of "misbehaving issuer". How are these defined?

One inadequate definition is:

• an issuer misbehaves if it returns any purses/payments that are not valid (in the sense of reasoning about risk ... in open world)

but we have since discussed some liveness obligations or something.

Description of the Design

??

Security Considerations

IOU

Test Plan

ideally: model-generated testing from TLA+ tools

Documentation considerations

This should be in or linked from API docs.

[mhofman]

Related: Agoric/agoric-sdk#1271

[dckc]

@erights suggests the liveness obligations come down to: all requests complete promptly, aka eventually.

I intend to see that this is adequately documented.

[dckc]

@Tartuffo while I agree we should address this in due course, I think we can ship MN-1 without it.

[Chris-Hibbert]

cap-lore.com (at the indicated link) says

In the case of the space bank then, promptness means that the bank will respond to a space request without invoking any code outside the space bank and the bank’s TCB. Headway may thus be ensured.

This seems closer to the sense I had of the intent. There's no particular time-constant for the response, but something advertised as prompt shouldn't wait behind arbitrary other computation. @erights, do you think promptness is looser than that?

[erights]

Depends what you mean by "shouldn't wait behind arbitrary other computation". Even in Norm's example, if the scheduler has scheduled a ton of things ahead of this prompt action, it will still happen eventually, but there's nothing tighter we can say in general.

Likewise, I think our liveness/promptness guarantees cannot in general be made stronger than "eventually".

Was this issue only about liveness? @dckc Should we close?

[dckc]

Was this issue only about liveness?

Yes, I believe the liveness constraint completes the definition.

@dckc Should we close?

Not until we make the definition available to relevant audiences in API documentation and/or JSDoc.

[Tartuffo]

Is this needed for Mainnet 1?

[dckc]

No.

Presuming you're asking me, since this is assigned to me... though now I'm a little confused, since I tried to say as much in #663 .

[Chris-Hibbert]

see #5798

[dckc]

@Chris-Hibbert I don't see the relevance. help?

[Chris-Hibbert]

Sorry, I meant this comment specifically.

The Timer/TimerBrand pair is closely analogous to the Issuer/Brand pair. One can ask a Timer for its TimerBrand. One cannot ask the TimerBrand for its Timer. However, one must be able to ask the TimerBrand "is this your Timer"? That way, a client like Zoe that has both a Timer and TimerBrand that allegedly agree can ensure that both the Timer and TimerBrand agree on the correspondence at least once. If they were both well behaved, the correspondence will be stable. If only one is well behaved, by definition it won't agree on the other. Only if they are jointly ill behaved, they can still damage only themselves and those who relied on them being well behaved.

Without this, a malicious Timer can claim that another Timer's TimerBrand is its own. Zoe does check the mutual agreement of Issuer and Brand before registering them. Zoe would need to do the same thing here.

Without the cross-check between issuer and brand, a malicious Brand can claim that another Issuer's Brand is its own.

So one aspect of a malicious Brand would be claiming an Issuer that doesn't refer back to it.