--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CALTyOpEYtUTekAkCdoCx-hxH0%3DoyNy8UOn0R0ZVX7eR%2BweRmQw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAAr2UCxVOKEtZJq4NLZm7-KQBiCMBW9p6rQL8sKDVGJ4RUxjXA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAJy9O61pLRAf4txha9yZgLNuqLD6TkxmNwuiF8-beqC%3D0jgoVQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/8764acca-124c-4461-8bcd-f8047a602f55%40Spark.
I'm all for this feature as I believe it opens the doors for more regulated players to utilize the Stellar ecosystem. They have a different set of requirements than your average asset. If also used in good faith, it would help deter attempted hacks on a given coin if the attacker knows it's a fruitless effort. AUTH_REVOCABLE doesn't achieve this same effect as you essentially burn tokens in the process if you have a fixed supply, and burning money out of thin air is really not the net effect a regulated asset would be looking for.
On Mon, Mar 2, 2020 at 8:16 PM 'Tyler van der Hoeven' via Stellar Developers <stell...@googlegroups.com> wrote:
A good use case for revokable is in the case of unauthorized access. Locking up an account so funds can’t be removed to a hackers account. Once the account is stable again the flag can be removed.I do think it’s a bit nervous to live underneath clawback. At any moment you could have your assets reclaimed. I would want time or amount or both restraints added to that.
Tyler
On Mar 2, 2020, 6:35 PM -0500, 'Ishai Strauss' via Stellar Developers <stell...@googlegroups.com>, wrote:
If an anchor revokes a trustline, then the user needs to send the entire balance back to the issuing account. The anchor can send back whatever fraction it does not want to clawback and then reauthorize the trustline. I'm not really against the clawbackable flag, just playing devil's advocate really.Another question, if a clawback flag is introduced, is revocable still necessary? What are the use cases where I want to revoke but not clawback?
On Mon, Mar 2, 2020 at 5:29 PM Tomer Weller <to...@stellar.org> wrote:
Ishai, that's an acceptable (though a bit hacky) solution for the first problem - we can just agree that unauthorized balances don't count towards the circulating supply. But what about a partial clawback (only a part of the account's balance)?
On Mon, Mar 2, 2020 at 3:25 PM Ishai Strauss <is...@stellarport.io> wrote:
What is the difference between a clawback and a revocation? I mean, if I as an anchor revoke a user's trustline then all I need to do is make sure I never credit the user if they send back to the issuing address, isn't that essentially a clawback?
On Mon, Mar 2, 2020 at 5:17 PM 'Tom Quisel' via Stellar Developers <stell...@googlegroups.com> wrote:
I like it! One idea is to simply add a clawback feature to the existing AUTH_REVOCABLE flag, since it's arguably a lesser power over the user than completely revoking their trustline.Tom
On Mon, Mar 2, 2020 at 3:11 PM 'Tomer Weller' via Stellar Developers <stell...@googlegroups.com> wrote:
--Some regulated asset issuers are interested in the ability to claw back assets unilaterally to comply with various regulations.The Stellar protocol allows revoking ("deauthorizing") trustlines. However, that doesn't completely solve the problem. First, the balance remains in the unauthorized trustlines. Second, there's no way to claw back a partial balance.One potential solution: add an "AUTH_CLAWBACKABLE" (or better name) account flag. If an asset is clawbackable then the issuer can authorize payments from all trustlines to their assets.Would love to hear your thoughts on this
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stell...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CALTyOpEYtUTekAkCdoCx-hxH0%3DoyNy8UOn0R0ZVX7eR%2BweRmQw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stell...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAAr2UCxVOKEtZJq4NLZm7-KQBiCMBW9p6rQL8sKDVGJ4RUxjXA%40mail.gmail.com.
--
Ishai StraussFounder/CEO Stellarport
--
--Ishai StraussFounder/CEO Stellarport
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stell...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAJy9O61pLRAf4txha9yZgLNuqLD6TkxmNwuiF8-beqC%3D0jgoVQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stell...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/8764acca-124c-4461-8bcd-f8047a602f55%40Spark.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/dee593a8-606c-45eb-bf53-3aa37dbd0be7%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAOXghCZsSEJj757AUv31nC6d3QONtYxa%2B8dMW-1nzLsorV78BQ%40mail.gmail.com.
RE: https://github.com/stellar/stellar-protocol/pull/736>In order to execute a clawback, the Issuer submits a a `CLAWBACK` operation
>from the account containing the asset to be clawed back to the desired
>destination.If the issuer of the asset must be the source account of the operation, this means the issuer keys can never be discarded. This would make this feature incompatible with assets where the asset issuer wishes to prove definitively that the asset has a finite supply by locking the issuing account. Maybe that makes sense in that situation? Would clawback still be useful on assets that have a finite supply? I would think so, but I'm not sure.Leigh
Thanks for submitting this proposal! I posted some corrections on the PR, but I will share some discussion points here.
> The account CLAWBACK_ENABLED flag allows the issuer to designate the asset as a non-bearer instrument asset. By including the CLAWBACK_ENABLED flag in Asset flags, Account owners may review the revocability of an asset and have the choice to avoid this type of asset if they object to the implied trust in the issuer.
I think this exaggerates how easy it will be for users to determine that an issuer can clawback. As long as AUTH_IMMUTABLE is not set, it would be possible for the issuer to set CLAWBACK_ENABLE whenever they like. A “sandwich” transaction like
1. Set CLAWBACK_ENABLE
2. Clawback
3. Clear CLAWBACK_ENABLE
would even be possible, in which case the CLAWBACK_ENABLE flag never remains in the set state.
> The change does not have an affect on previous assets, accounts, or transaction structure. It should not cause a breaking change in existing implementations.
Using the same argument as above, this does impact existing assets. Any asset that does not have AUTH_IMMUTABLE set is now effectively non-bearer. Perhaps this doesn’t matter, because accounts that hold these assets could already have their authorization revoked.
> In the future, we expect that this flag may also be used to support transaction compliance rollback. While under this specification a rollback (reversing a transaction) can be achieved with the issuer executing a clawback from a transaction’s beneficiary and subsequent payment to the originator, we believe it may be beneficial to explicitly support a rollback transaction. In any case, this transaction is not covered here.
Perhaps this is outside the scope of this proposal, but I believe it is not generally possible to design a mechanism to rollback a transaction. Even a simple payment cannot necessarily be rolled back. Imagine I send a payment to you, and the issuer later wants to roll this back. You have potentially made payments to many accounts since then, and may not hold any of the funds. In order to roll this back, you would have to rollback the entire tree of transactions. Perhaps this can be done, but this is assuming that only simple payments happened. If asset exchange is involved, then this may be completely impossible because you may not be the issuer of the assets for which your asset was exchanged. You will not be able to unilaterally rollback those operations under any circumstances. What do you desire in terms of rollback, given these practical constraints? Or am I missing some important detail?
> Clawback will cancel as many pending orders as necessary, in order of creation, to ensure that account liabilities are maintained.
From an implementation perspective, this is a bit of a pain. Would it be acceptable to take the stance that authorization must be revoked before CLAWBACK? Then we wouldn’t have to implement any new logic to remove orders, because this is already done when revoking authorization. The main difference is that all orders for that account involving the asset would be cancelled, instead of just a subset. Since I don’t expect CLAWBACK to be a regular occurrence, this seems okay to me but perhaps others disagree.
In general, I believe that anyone trying to use CLAWBACK would want to revoke authorization first anyway. Otherwise the account could consistently reduce their balance by a random amount in order to prevent the CLAWBACK from succeeding due to CLAWBACK_UNDERFUNDED.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/34e6ba44-72af-40b7-bff7-31c8b9b4dacan%40googlegroups.com.
>> The account CLAWBACK_ENABLED flag allows the issuer to designate the asset as a non-bearer instrument asset. By including the CLAWBACK_ENABLED flag in Asset flags, Account owners may review the revocability of an asset and have the choice to avoid this type of asset if they object to the implied trust in the issuer.
>I think this exaggerates how easy it will be for users to determine that an issuer can clawback. As long as AUTH_IMMUTABLE is not set, it would be possible for the issuer to set CLAWBACK_ENABLE whenever they like. A “sandwich” transaction like
>1. Set CLAWBACK_ENABLE
>2. Clawback
>3. Clear CLAWBACK_ENABLE
>would even be possible, in which case the CLAWBACK_ENABLE flag never remains in the set state.
This is a good point. I sympathetic to this issue and believe that transparency is best for: the 1) protection of those who like the censorship free aspects of bearer instruments, and 2) convenience of those who require/desire revocable instruments. There are 2 ways we could address this issue: 1) require the flag to be set at issuance - it can't be toggled. 2) have an additional flag CLAWBACK_DISABLED, that once set, cannot be unset. Setting this flag, disables CLAWBACK_ENABLE. This is the equivalent of AUTH_IMMUTABLE, but only for the CLAWBACK parameter.
>> In the future, we expect that this flag may also be used to support transaction compliance rollback. While under this specification a rollback (reversing a transaction) can be achieved with the issuer executing a clawback from a transaction’s beneficiary and subsequent payment to the originator, we believe it may be beneficial to explicitly support a rollback transaction. In any case, this transaction is not covered here.
> Perhaps this is outside the scope of this proposal, but I believe it is not generally possible to design a mechanism to rollback a transaction. Even a simple payment cannot necessarily be rolled back. Imagine I send a payment to you, and the issuer later wants to roll this back. You have potentially made payments to many accounts since then, and may not hold any of the funds. In order to roll this back, you would have to rollback the entire tree of transactions. Perhaps this can be done, but this is assuming that only simple payments happened. If asset exchange is involved, then this may be completely impossible because you may not be the issuer of the assets for which your asset was exchanged. You will not be able to unilaterally rollback those operations under any circumstances. What do you desire in terms of rollback, given these practical constraints? Or am I missing some important detail?
Let's table this for a future proposal. One comment though, the funds could be locked until rollback time period expired or compliance entity issues a release.
>> Clawback will cancel as many pending orders as necessary, in order of creation, to ensure that account liabilities are maintained.
>From an implementation perspective, this is a bit of a pain. Would it be acceptable to take the stance that authorization must be revoked before CLAWBACK? Then we wouldn’t have to implement any new logic to remove orders, because this is already done when revoking authorization. The main difference is that all orders for that account involving the asset would be cancelled, instead of just a subset. Since I don’t expect CLAWBACK to be a regular occurrence, this seems okay to me but perhaps others disagree.
You are probably right. Let's keep it simple. All orders should be disabled.
> In general, I believe that anyone trying to use CLAWBACK would want to revoke authorization first anyway. Otherwise the account could consistently reduce their balance by a random amount in order to prevent the CLAWBACK from succeeding due to CLAWBACK_UNDERFUNDED.
I'd prefer one transaction. But I don't have a strong opinion here.
Reviving this thread so that we keep things moving.
I took a look at the current CAP.
# semantics
## Relationship with authorization
It looks like the feedback from JonJove above was not incorporated into the CAP? I suspect that in order to "clawback" from a trustline, a prereq is that the trustline must first be set into "not authorized" state so that it's easy to understand what happens when a clawback happens/is in process.
## Interaction with the order book
From JonJove: the CAP still describes some arbitrary order cancellation. At the core layer I'd expect all offers related to an asset to be cancelled during the "clawback" flow, to avoid this kind of problems (I think addressed by requiring to de-authorize first).
## Interaction with `BalanceEntry`
NB: most of the issues described here also apply to any "smart contract" type of setup with an escrow account of sorts.
The CAP as described creates an incentive for people to "stash" their balance in a `BalanceEntry` as there is no way to clawback from a `BalanceEntry`.
I am not 100% sure what the right solution in this situation is yet.
One way can be to just not allow accounts that can be the target of a "clawback" to create a `BalanceEntry` or to limit the amount stored in those (with the understanding that those could be "lost"). The big downside is that such accounts may have limited interop with interesting smart contracts, in particular Layer 2 payment infrastructure and are just "stuck" with on chain transactions.
Allowing to clawback from `BalanceEntry` in some way is probably not viable:
* we want to keep `BalanceEntry` immutable
* we could make it that the issuer can "claim" those, but
* this may break certain smart contracts
* we're now shifting the problem to
conditions on claimants and as those can be arbitrary, we'd have to allow
bypassing conditions (or we're back to cooperating/waiting), which again potentially breaks smart contracts..
Above, the reason I am focusing on "breaking smart contracts" is that the breaks can have implications way beyond the asset being clawed back: we do not want side effects of a clawback to impact other assets and other accounts.
# Unspecified behavior
## flags
It looks like the CAP is missing the expected behavior wrt `SetOptions`. In particular, are there any invalid flag combinations or transitions? When can the flag be set? Should there be a way to express something like "this asset will never be clawback" (that should be the default). I saw a response earlier that started to discuss something like `CLAWBACK_DISABLED` which may not meet the "backward compatibility" requirement for existing assets.
## threshold
The threshold is not defined in the CAP, the choice and justification needs to be incorporated for further discussion. I see arguments for "high" or "low" in this thread, even though "medium" is the threshold typically used for sending assets (including issuing).
# Minor points
## general CAP structure
The CAP uses the "old" template, you may want to update it to use the new template that has some additional questions/sections to help move things along.
## naming/cleanup
(should probably be done when draft is getting close to final quality)
We may want to extract the "issuer less" asset definition, it looks like this is a copy/paste from `AllowTrustOp`.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/6d5c335d-91eb-48da-a542-39ba26b8e6a1n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/0cf46754-740f-415c-9ebc-e156dbcfee4en%40googlegroups.com.
Reusing AUTH_REVOCABLE for clawback will subject existing trustlines and claimable balances to clawback semantics, which will be an added burden for developers who only deal with "non-clawbackable" assets. It would be simpler and less invasive if the ability to clawback from trustlines and claimable balances were explicitly added on to the trustline.
Our proposed changes-
Add AUTHORIZED_TO_CLAWBACK_FLAG to TrustlineFlags.
Add a DEFAULT_TO_CLAWBACK_FLAG account flag, which will operate similar to AUTH_REQUIRED_FLAG (side note - the name of this flag is not ideal. While it is enabled, any trustline created will not have AUTHORIZED_FLAG set by default). If DEFAULT_TO_CLAWBACK_FLAG is enabled on an issuer when it creates a trustline, that trustline will have AUTHORIZED_TO_CLAWBACK_FLAG enabled.
AUTHORIZED_TO_CLAWBACK_FLAG can only be set on the trustline when it is created. It can never be set on an existing trustline.
A clawback from a trustline will work like it does in the CAP-0035 proposal, with the only difference being that the trustline flag AUTHORIZED_TO_CLAWBACK_FLAG will be checked instead of the issuer accounts AUTH_REVOCABLE flag.
Clawbacks will work differently for claimable balances. If an account tries to create a claimable balance for an asset that has AUTHORIZED_TO_CLAWBACK_FLAG enabled, the operation will fail unless the issuer is a claimant on the claimable balance with a CLAIM_PREDICATE_UNCONDITIONAL predicate. This will ensure that an issuer can always claim a claimable balance that is subject to clawbacks.
These changes would allow existing trustlines and claimable balances to not be affected by clawbacks. The clawback implementation for claimable balances is also simpler.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/557a68e1-0efa-4c9a-a4d6-7a9ca047f069n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/c84a08be-b8b0-461d-bb6f-7dc8bd883432n%40googlegroups.com.
AllowTrustOp
operation to revoke authorization of the trustline, which will cancel any existing ledger entries creating selling liabilities, such as offers, and issue the ClawbackOp
in the same transaction. If the issuer wishes to allow the from
account to continue utilizing the asset it can include another AllowTrustOp
after the ClawbackOp
to authorize the account once again.To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/8e4b5b59-1089-4030-b7f8-856bf198b3a3n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/c5af952e-42ec-4d17-9f6f-b25ad4bee7d4n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/7d615531-59f1-4aaa-9b6f-293b726db919n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/708b9e55-436d-4f2e-8b1b-d383a0dc4874n%40googlegroups.com.