Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transfer only to whitelisted Accounts and trade only with whitelisted Assets #1044

Open
fractalnode opened this issue Jun 12, 2018 · 5 comments
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2a Discussion Needed Prompt for team to discuss at next stand up. 3b Feature Classification indicating the addition of novel functionality to the design 4a Low Priority Priority indicating minimal impact to system/user -OR- an inexpensive workaround exists 6 API Impact flag identifying the application programing interface (API) 6 CLI Impact flag identifying the command line interface (CLI) wallet application 6 Protocol Impact flag identifying the blockchain logic, consensus, validation, etc. 6 Security Impact flag identifying system/user security 6 UX Impact flag identifying the User Interface (UX) feature hardfork

Comments

@fractalnode
Copy link

As a user with security concerns I would like to secure my additional accounts by limiting the ability to transfer tokens only to whitelisted accounts. Additionally, I would like these accounts to be able to exchange tokens only for whitelisted tokens

Two new policy mode:

  • TRANSFER FUNDS TO WHITELISTED ACCOUNTS ONLY (Allow ALL by default)
    [comma separated list: eg. my-bot-1, my-bot-2, my-primary-account-1, my-primary-account-2]

  • TRADE WITH WHITELISTED ASSETS ONLY (Allow ALL by default)
    [comma separated list: eg. BTS, bitUSD, bitCNY]

whitelist can only be managed by the Account Owner (OWNER Priv Key).
Such permissions would have to be given separately for each ACTIV key (if there are more than 1)

if ACTIVE key get compromised by the hacker, He would by able to "bad trade" on defined trading pairs and he will not be able to transfer funds to account other then whitelisted

@abitmore
Copy link
Member

Please be aware that there are tons of things that can be done with an active key, but not only limited to transfers and trading, to make you loss your money, E.G. reserve asset, fund fee pool, withdrawal permission, creating vesting balance, stealth transfer and etc. That said, DON'T loss your active key, and, don't use owner key too frequently.

I remember we already have an issue here or in another Github repository about the feature requested in OP.

A possible approach is to have new key pairs which can only do limited and configurable things, something in addition to current account authorization mechanism. It's not a simple task, so need much more discussion. By the way, IMHO this feature is not for an average Joe, thus low priority.

@fractalnode
Copy link
Author

fractalnode commented Jun 12, 2018

A possible approach is to have new key pairs which can only do limited and configurable things, something in addition to current account authorization mechanism.

This is what i have in mind.
E.g. "withdrawal permission", "Transfer", (...) depends on MEMO so if you don't have MEMO, then you can't send funds.

image

If your password creates only ACTIVE Key, like in this case ↑, user is more secure. But this is not perfect either. That's why I wanted to whitelist some features

@abitmore
Copy link
Member

I meant to change the code to introduce new key pairs in addition to current owner/active schema, with a BSIP and hard fork. I didn't mean to add one more key to your account now.

@ryanRfox ryanRfox added 1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2a Discussion Needed Prompt for team to discuss at next stand up. 3b Feature Classification indicating the addition of novel functionality to the design 4a Low Priority Priority indicating minimal impact to system/user -OR- an inexpensive workaround exists 6 API Impact flag identifying the application programing interface (API) 6 CLI Impact flag identifying the command line interface (CLI) wallet application 6 Protocol Impact flag identifying the blockchain logic, consensus, validation, etc. 6 Security Impact flag identifying system/user security 6 UX Impact flag identifying the User Interface (UX) labels Jun 12, 2018
@ryanRfox
Copy link
Contributor

@fractalnode great User Story provided. I look forward to refining/enhancing it with input from the Community going forward. Many bits to consider.

@abitmore
Copy link
Member

Please discuss in bitshares/bsips#86

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2a Discussion Needed Prompt for team to discuss at next stand up. 3b Feature Classification indicating the addition of novel functionality to the design 4a Low Priority Priority indicating minimal impact to system/user -OR- an inexpensive workaround exists 6 API Impact flag identifying the application programing interface (API) 6 CLI Impact flag identifying the command line interface (CLI) wallet application 6 Protocol Impact flag identifying the blockchain logic, consensus, validation, etc. 6 Security Impact flag identifying system/user security 6 UX Impact flag identifying the User Interface (UX) feature hardfork
Projects
None yet
Development

No branches or pull requests

4 participants
@abitmore @ryanRfox @fractalnode and others