semantics of AUTH_REQUIRED and AUTH_REVOCABLE

[Tomer Weller]

They don't always make sense:

1. If an asset is modified from being AUTH_REQUIRED=true to AUTH_REQUIRED=false, all previous unauthorized trustlines remain unauthorized but can't be allowed trust (op_not_required), unless you modify AUTH_REQUIRED to true, which means sandwiching ALLOW_AUTH ops with SET_OPTIONS before/after to set AUTH_REQUIRED true and then false.

2. if an asset is AUTH_REQUIRED=false and AUTH_REVOCABLE=true issuer can't actually revoke a trustline (op_not_required).

1 - a lot of  plumbing involved.

2 - (a) why is it  allowed to have AUTH_REVOCABLE without AUTH_REQUIRED if it does nothing? and (b) many times asset issuers want the default authorization to be true but be able to revoke, which can't be done right now. (super common in stable coins in other networks)

What might make sense:

AUTH_REQUIRED can be the default state of authorization. It's the state of a trustline when a new one is formed.

AUTH_REVOCABLE allows the issuer to ALLOW_AUTH from true to false, regardless of AUTH_REQUIRED.

ALLOW_AUTH from false to true should always be permissible.

Thoughts?

[Tomer Weller]

Actually, 2 can be solved with the same type of mechanics as 1. The issuer will normally have both flags set to false, and when they want to revoke a trustline they'll start by setting both to true, ALLOW AUTH false, and then both flags back to false. Only problem is you can never really set IMMUTABLE to true. 

[tomer]

I wrote a CAP to address these issues: https://github.com/stellar/stellar-protocol/blob/master/core/cap-0029.md. Would love to hear your thoughts. 

Note: In my previous email I outlined a hack to bypass the problem of revoking a non `AUTH_REQUIRED` asset. However, my proposal required the signing weight to have a weight of `HIGH` on the issuer while ALLOW_TRUST usually requires a threshold of LOW. That's a major security concern so it should be avoided.