[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.

[abitmore]

I suggest that we submit BitShares (the blockchain) related issues here: https://github.com/bitshares/bitshares-2/issues, and probably also move old open issues/discussions over there, for better project planning/management. @vikramrajkumar your opinion?

Actually this feature was in my plan when implementing BSIP10 (#583).

[vikramrajkumar]

Yes, there has been little to no activity from Cryptonomex in this repo for some time, whereas https://github.com/bitshares/bitshares-2 can continue to see activity from the decentralized BitShares community.

For example, after recently taking over BitShares administration, @abitmore I merged some of your fixes

• bitshares/bitshares-core@aa844f5
• bitshares/bitshares-core@ead2db3
• bitshares/bitshares-core@5ad763b

Which had previously been left only in this inactive Graphene repo for some time.

It seems inevitable to me that BitShares will continue to diverge and evolve to be managed independently of the original Graphene, so I encourage you to make future contributions directly to the BitShares repo. This is also indeed why I enabled the BitShares issue tracker https://github.com/bitshares/bitshares-2/issues. Perhaps the important issues can be transitioned by: creating a new issue in the BitShares tracker when there is new discussion/information/updates and linking back to the previous discussion for the previous context.

@svk31 I'd also be interested in any thoughts you might have on how you want to manage https://github.com/cryptonomex/graphene-ui vs https://github.com/bitshares/bitshares-2-ui.

[dnotestein]

The original idea was that grahene repo was going to be for all graphene-based chains, with bitshares repo only for bitshares-specific changes (e.g. not many of these). If we start making basic changes only to bitshares, do we expect future chains to fork from bitshares? Or cherry-pick the changes over to their repo after forking from graphene?

[vikramrajkumar]

@dnotestein My thinking is that BitShares is more likely to see activity and evolution as time goes on, from its decentralized community, some of whom do not necessarily care about the vanilla Graphene heritage. So if BitShares does indeed receive more updates, in practice people will likely fork from BitShares.

[vikramrajkumar]

This issue was moved to bitshares/bitshares-core#218