[Feature Suggestion] No Fee on User Side with Whitelisted UIA

[clayop]

If a UIA issuer has authority to allow or deny users with whitelisting, a possibility of spam attack can be significantly reduced and easily controlled out. In this case, a UIA issuer may want to remove transaction fees from users to facilitate UIA usage, while the issuer pays the fee through the fee pool.

There is a potential customer in Korea(a local government) and if this feature is implemented, we are going to push it more.

Note: The original issuance is here

[nathanielhourt]

This sounds like a useful feature. In my work at FMV, we encountered some scenarios where this would substantially simplify the blockchain app.

[clayop]

Definately, especially for real-world use cases. One of the goal of charging fee is to prevent spam from anonymous attackers. However, if we know identity, or at least we have a control on access permission, we can kick the attackers out (even legally) or block suspicious accounts.

[abitmore]

This can be done in UI.

The business owner create another UIA, say, named XFEE, show it in UI as allowance or so, carefully maintain the core exchange rate, fee pool and white list, dynamically issue/send some amount of the UIA to users according to their reputation or whatever. Whenever a user transact, pay an amount of the UIA from the user's account, so equivalent CORE will be deducted from the fee pool.

[abitmore]

Here is another approach. With a customized UI, the end user can feel no fee is involved, even no need to create a special fee asset, nor need to maintain the fee pool.

Knowledge points:

• fees are paid after an operation got executed;
• it's able to pull funds from another account.

Preparation:

• initialize withdraw permissions for your user with withdraw_permission_create_operation

When a user requests a transfer, create a transaction which contains 2 operations:

1. withdraw_permission_claim_operation: pull required fees (can be in BTS) from the account configured by asset owner, fees of this operation can be paid with a part of pulled funds,
2. transfer_operation: the real transfer, pay fees with the rest of pulled funds.

Total fees required would be sum of the 2 operations.

UI/UX:

• hide the fee field,
• hide the withdraw_permission_claim_operation,
• handle exceptions e.g. an user has exceeded her credits thus unable to pull funds (UI should already know that and why).