Interoperability with Regulated Assets (SEP-8)

[accordeiro]

The current Payment Protocol draft does not suggest anything with regards to Regulated Assets, i.e. assets whose issuer has the Authorization Required and Authorization Revocable flags set to true in their account and usually operate through the Regulated Assets Protocol (SEP-8).

The authorization protocol described in SEP-8 can definitely be applied at each Payment Channel update, but this could potentially reduce the throughput, as a few extra roundtrips would be involved in the process, and an issuer of a regulated asset could effectively halt a Payment Channel.

Is this something we need to worry about for v1? @tomerweller @leighmcculloch @JakeUrban would love your thoughts on this.

(This topic originated in #20)

[leighmcculloch]

I think regulated assets scoped to what is defined in SEP-8 should work.

As you suggest, two participants could involve a regulated asset server in the auth and deauth of their escrow accounts by having the regulated asset server sign every closing transaction. Nothing would need to change about SEP-8 or the channel protocol to support this today, except for the inclusion of allow trust operations within the setup, formation, and closing transactions. If the regulated asset server disagrees with a payment channel payment it would be just like one party disagreed (which we don't yet discuss in the SEP but we will once I get to #27).

The performance aspect seems unavoidable with what we have in the protocol at the moment. There are probably some things we could do at the protocol level to allow two escrow accounts to transact freely but not allow them to transact with others, but this would be another CAP.

Another place where regulated assets fall apart is if the state of the issuer account changes, such as the signers change, or the account is merged. In both cases the closing transactions would fail, so regulated assets would only be truly safe if the high threshold is set higher than all the signers combined have weight for. This would disallow merging and changing of signatures, but continue to allow the allow trust operation.

Even if all the above is correct, an issuer using regulated assets who is using clawback could still break the channel.

[leighmcculloch]

Actually something to consider is that a SEP-8 server will be able to respond much faster than the network will. Network confirmation is about 5 seconds. An average web server is going to respond in under 1 second. So channels with SEP-8 would still be faster. But, if we could find a way to do the in channel updates without the SEP-8 server that would be great.

[leighmcculloch]

I think there's a lot of issues, that might not all be as critical, so I'm going to try and break them down.

1. Clawback and auth revocation used on an escrow account can cause the closing transactions to fail. If the channel contains more than one asset this is especially problematic because the issuer who causes the channel to break will have no capabilities to reissue other assets that are potentially lost within the channel.

2. Issuer signers may change, which would invalidate any closing transaction that had their signatures if SEP-8 was involved.

3. Clawback and auth revocation may be directed at only one of the two escrow accounts, but it won't be clear who owns what assets if both participants own the asset in the escrow account affected.

[leighmcculloch]

I think issue 1 is worth solving. I don't know if issue 2 is.

A solution to issue 1 is here: #34 (comment).

[accordeiro]

When thinking about clawbacks, two things come to mind:

• I wouldn't expect serious issuers to do clawbacks haphazardly: they'd probably only do a clawback to an account after doing their due diligence, so it seems unlikely that they would target a Payment Channel, and if they did it would be intentionally.
• I wonder if we should make it as part of the protocol that we should somehow signal to the world that that account is a payment channel / escrow account. Then we could recommend that people check for that flag before doing a Clawback, since it'd be a destructive operation.

What do you think?

[leighmcculloch]

I think the first point you make is accurate. And a serious issuer is going to be performing a clawback from some legal actions, or some regulatory requirement, where the owners of the assets should have been well established. So in that case it is probably known that the escrow account has multiple owners and the action may impact the other party. Possibly the issuer will compensate or address any unfair exchange through issuing directly to the other party if only one party is to be expected.

[leighmcculloch]

For issue (1), we either need:

1. A way to prevent clawback and auth revocation on payment channels.
2. A way to allow a clawback or auth revocation to only affect the disbursement of that specific asset.

I think preventing is hard and is just one way of saying regulated assets are incompatible. I think we need to allow clawback and revocation, but we need to make it so that if that occurs, the channel is still open for business and other assets held in the channel are unaffected, and the existing close transaction would still work and the affected payment would be ignored.

I can think of a few possible solutions:

1. Allow operations to fail in a transaction if they've been marked as being allowed to fail. The transaction would succeed. Other payments would succeed.

2. Separate the disbursement from the change in signers of the escrow accounts, so each disbursement is a separate transactions that can be executed between the declaration and close transactions. The close process would be more complex. This should require zero changes to the protocol.

Both of these ideas have problems, the payment failing might leave the two participants in an unfair state, but at least one issuer can't lock up assets of other issuers.

I think solution (2) would be relatively easy to add to the SEP.

[acharb]

1. Allow operations to fail in a transaction if they've been marked as being allowed to fail. The transaction would succeed. Other payments would succeed.

that’s a protocol change right? Currently that’s not possible to designate operations as fail-able

[leighmcculloch]

Yup that's a protocol change, and a rather nasty and controversial one I think.

I think solution (2) (#78) is much more sane, and doesn't require a protocol change.

[accordeiro]

I really like solution 2. What are the tradeoffs? Is it just slightly more expensive the more assets you add, and slightly more complex to implement?

[leighmcculloch]

More expensive because you have to submit more transactions, but transactions are cheap and people can't have more than 1000 trustlines on any Stellar account, so seems like a small issue. The complexity change isn't significant, except calculating s_i and s_e will now be more difficult.

I think the biggest tradeoff is we're saying any unfair exchange that results as part of a clawback or auth revocation of an asset must be coordinated off chain.

[leighmcculloch]

Someone pointed out in discussion offline that we don't need #78 if we simply focus on single asset payment channels, which makes more sense at the moment because the use cases we have are single asset, so I've closed that proposal and am focusing on single asset instead: #144.