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

Whitelist Script for BEP12 #41

Closed

Conversation

wjmelements
Copy link
Contributor

Changes

Transactions can send money to the wrong address, causing immediate loss of value.
A whitelist could be useful for a wallet or service to protect against mistake transfers, as an additional safeguard.
This also proposes transactions for adding to the whitelist or removing from it.
Reviewers @huangsuyu

@wjmelements
Copy link
Contributor Author

I pushed a commit to make the parameters plural, which I see as an improvement, though it may complicate the fee structure. git revert be37795 if unwanted.

Proposed fee structure

To account for the increase in state size, adding whitelisted addresses should cost more per-account. However, because removing whitelisted accounts trims the state size, removing blacklisted accounts should have a smaller, flat fee.

#### New Transaction: WhitelistRecipients
A node should reject the transaction if any of the accounts are already whitelisted by this sender.

Parameters for adding whitelisted recipients:
Copy link
Contributor

@chainwhisper chainwhisper Jul 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to allocate extra space for whitelist storage. It will be a scalability issue.

@wjmelements
Copy link
Contributor Author

wjmelements commented Jul 30, 2019 via email

@HaoyangLiu
Copy link
Contributor

Overhead would depend on the node implementation. If the account is amino-encoded, for example, there is no extra space for null fields.

@huangsuyu means that this feature requires not only a validation script but also extra storage for saving whitelist.

@wjmelements
Copy link
Contributor Author

Overhead would depend on the node implementation. If the account is amino-encoded, for example, there is no extra space for null fields.

@huangsuyu means that this feature requires not only a validation script but also extra storage for saving whitelist.

added

@darren-liu
Copy link
Contributor

why cannot this be implemented on client side, i.e. wallets or signing service? They are more flexible to add more features, e.g. different group of white list can accept different size of fund, or an address book that can associate address with monikers to select.

Storing on chain cost token and actually exposes more privacy information of the addresses relationship. I don't think many people are interested.

@wjmelements
Copy link
Contributor Author

@darren-liu We (TrustToken) are interested in this as an additional layer of defense for our mint security, and have used a similar system on Ethereum in the past.

@brilliant-lx
Copy link
Contributor

outdate, archive it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants