-
Notifications
You must be signed in to change notification settings - Fork 586
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
Conversation
I pushed a commit to make the parameters plural, which I see as an improvement, though it may complicate the fee structure. Proposed fee structureTo 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: |
There was a problem hiding this comment.
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.
Overhead would depend on the node implementation. If the account is
amino-encoded, for example, there is no extra space for null fields.
…On Tue, Jul 30, 2019 at 1:13 AM huangsuyu ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In BEP12.md
<#41 (comment)>:
> + }
+ if ! isSender(tx, addr) {
+ return nil
+ }
+ if ! isRecipientWhitelisted(addr, tx) {
+ return err("recipient not whitelisted")
+ }
+ return nil
+}
+```
+
+
+#### 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:
We need to allocate extra space for whitelist storage. It will be a
scability issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGDGVK6IQBC32WNCSWN2ZTQB7Z2JANCNFSM4IHNW35A>
.
|
@huangsuyu means that this feature requires not only a validation script but also extra storage for saving whitelist. |
added |
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. |
@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. |
outdate, archive it. |
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