Operation to update `account_object::allowed_assets`

[abitmore]

Code:

bitshares-core/libraries/chain/include/graphene/chain/account_object.hpp

Lines 223 to 228 in 504aa5d

	/**
	* This is a set of assets which the account is allowed to have.
	* This is utilized to restrict buyback accounts to the assets that trade in their markets.
	* In the future we may expand this to allow accounts to e.g. voluntarily restrict incoming transfers.
	*/
	optional< flat_set<asset_id_type> > allowed_assets;

We can add/update an operation to change this field, so users can set a white-list to avoid being annoyed by airdrops.

[abitmore]

We can backport from Yoyow: https://github.com/yoyow-org/yoyow-core/blob/v0.3.0-180626/libraries/chain/include/graphene/chain/protocol/account.hpp#L316-L385

Need a BSIP.

[ryanRfox]

I'd like to begin drafting a BSIP for this feature. As a prerequisite, I would appreciate some feedback on the following user story to help frame it. Please provide comments on specification criteria that should be considered.

As an account owner authority I want the ability to define which assets are allowed to be transferred to my account balance(s) when the transfer operation is executed. Currently, and by default, “all” assets are allowed. The system must have a definition for “none” assets to allow owner authority to fully restrict any asset (currently existing and those created in the future) from being transferred into the account. This feature should neither impact the account’s ability to hold a balance of nor interact with the specified asset(s). The account should remain able to use any current balance of an asset to perform all operations: transfer, order create/cancel, issue asset, etc. The focus is to enable the account owner to restrict incoming assets to an account when the transfer operation is executed.

[pmconrad]

Would it make sense to have both a whitelist and a blacklist? Not sure if a use-case for a blacklist exists.

We cannot use the existing allowed_assets field for this (it's checked in many more places than just transfers). And I wouldn't port the new operations from Yowyow but instead simply add another extension field to account_update.

[abitmore]

The focus is to enable the account owner to restrict incoming assets to an account when the transfer operation is executed.

If only to restrict incoming transfer, we can't use allowed_assets because it's an overkill and likely have other side effects E.G. you can't do outgoing transfer.

And I wouldn't port the new operations from Yowyow but instead simply add another extension field to account_update.

The Yoyow approach has its advantage because it accepts a delta (or two). If to put a new field in account_update, likely we need to have all accepted assets in the operation, which is inefficient and expensive when the list is getting large (BTW I don't like how the votes are being updated now). On the other hand, account_update is already very complicated, IMHO it's better not to add more logic to it.

[ThomasFreedman]

Not sure why a delta is useful for this use case, but if it is and there are no negative side affects that come with the Yoyow code I see no reason to reinvent the wheel. Those considerations should be spelled out in the BSIP.

How do you see this feature working in the UI? Will it be simply a boolean to allow / disallow sharedroped assets (and that would require a way to differentiate sharedrops from regular transfers) or do you envision a more comprehensive UX that allows users to specify which assets should be allowed to be deposited? Conversely the UX could specify which assets should not be allowed to be transferred in, but I see that as far less desirable and also doesn't cover the assets created in the future.

It seems like it will be a bit tricky to allow sharedrops / transfers to work as they do now and also prohibit "unauthorized" deposits. Perhaps some type of "users authorized to deposit" with a wildcard for all users would be workable.

[abitmore]

Here is how to understand a delta: when a user has a white-list containing 100 assets already, if he wants to allow one more asset, an operation with a delta would be like "account A adds asset X101 to the white-list", the whole operation would be small because only need to specify one asset; if without delta, the operation would be "account A update the white-list to [X1,X2,...,X101]", that said, all assets need to be in the operation, thus a large operation.